Error Handling in 0.8

[jswrenn]

Overview

Zerocopy's deserialization methods will return Result instead of Option. The Err type of the Result will provide:

• the cause of the deserialization error
• access to the un-deserializable bytes

Motivation

Providing better error messages

As it stands, .unwrap() presently produces an uninformative error message. Using a custom error type will allow us to provide precise diagnostic text.

Providing programatic access to the cause of the failure

The bytemuck crate provides this information with its PodCastError type. A cursory search of Github suggests that this fidelity is useful to some customers.

Providing the original bytes

Our current API does not always provide access to the original bytes in the case of deserialization failure. For instance, attempting this:

loop {
    let Some((des, rem)) = T::mut_from_prefix(buffer) else {
        panic!("could not parse from {buffer:?}");
    };
    buffer = rem;
}

...produces this error message:

error[E0502]: cannot borrow `buffer` as immutable because it is also borrowed as mutable
 --> src/main.rs:9:38
  |
8 |     let Some((d, remainder)) = mut_from_prefix_split::<u8>(buffer) else {
  |                                                            ------ mutable borrow occurs here
9 |         panic!("could not parse from {buffer:?}");
  |                                      ^^^^^^^^^^
  |                                      |
  |                                      immutable borrow occurs here
  |                                      mutable borrow later used here

Steps

• Implement Proposal
  • Overhaul error reporting (enum version) #1144
• Make Unalign's methods return Result<_, AlignmentError<_, _>>
  • Use AlignmentError in Unalign's failure conditions #1198
• Resolve undecided API issues, either:
  • Make ConvertError public, or
  • Evolve the API towards Overhaul error reporting (struct version) #1150