84 lines
3.3 KiB
Org Mode
84 lines
3.3 KiB
Org Mode
#+TITLE: Handling Multiple Possible Errors in Rust
|
|
#+DATE: 2022-08-04
|
|
#+FILETAGS: programming
|
|
#+HUGO_DRAFT: t
|
|
|
|
* Background
|
|
:PROPERTIES:
|
|
:CUSTOM_ID: background
|
|
:END:
|
|
Rust handles errors better than any other language I've ever used. All possible errors are known at build time, and by design Rust forces you to at a bare minimum /acknowledge/ that these errors are possible with =.unwrap()=, otherwise writing specific error handling logic.
|
|
|
|
** The =Result= enum
|
|
:PROPERTIES:
|
|
:CUSTOM_ID: the-result-enum
|
|
:END:
|
|
All of this is thanks to the =Result= enum, which is defined as follows:
|
|
|
|
#+begin_src rust
|
|
enum Result<T, E> {
|
|
Ok(T),
|
|
Err(E),
|
|
}
|
|
#+end_src
|
|
|
|
=Result= is a generic type that requires two type parameters, =T=, the actual value the result is wrapping, and =E=, the error type in case something goes wrong. In the success case, the =Ok(T)= variant will be used, and in an error case, =Err(E)= will be used.
|
|
|
|
What makes this powerful is the fact that since =Result= wraps the actual result value, access to that value is prevented unless the possibility of an error is acknowledged.
|
|
|
|
** Handling =Result=
|
|
:PROPERTIES:
|
|
:CUSTOM_ID: handling-result
|
|
:END:
|
|
For the sake of example, say we're writing a theoretical function, =acquire_banana=, that drives to the store, purchases a banana, and returns the banana.
|
|
|
|
We have a function called =drive_to_store=. It returns a =Result= that can either be nothing =()=, or a =NavigationError=.
|
|
|
|
#+begin_src rust
|
|
fn drive_to_store() -> Result<(), NavigationError> { ... }
|
|
#+end_src
|
|
|
|
We then have the following function, =acquire_banana=. It also returns a =Result=, but this time it can either be a =Banana= or a =PurchaseError=.
|
|
|
|
#+begin_src rust
|
|
fn purchase_banana() -> Result<Banana, PurchaseError> { ... }
|
|
#+end_src
|
|
|
|
In other languages, we might write the function something like this:
|
|
|
|
#+begin_src rust
|
|
fn acquire_banana() -> Banana {
|
|
drive_to_store();
|
|
purchase_banana()
|
|
}
|
|
#+end_src
|
|
|
|
However, this doesn't work in Rust. There are two issues here. First, while =drive_to_store();= is in theory valid code (it returns an enum that we ignore), =Result=s *must* be handled. Otherwise, you will get compile warnings. Second, we cannot return =purchase_banana= from the function, because its return type is =Result<Banana, PurchaseError>=, not =Banana=.
|
|
|
|
The naïve solution to this would be using the =unwrap= method on the =Result=s, like this:
|
|
|
|
#+begin_src rust
|
|
fn acquire_banana() -> Banana {
|
|
drive_to_store().unwrap();
|
|
purchase_banana().unwrap()
|
|
}
|
|
#+end_src
|
|
|
|
The =.unwrap()= method does exactly what it sounds like. If a =Result= is the =Ok(T)= variant, it returns =T=. However, the naïvety here lies in what happens on the =Err(E)= variant. In that case, it /panics/, printing the error and kills the thread/program. A well-designed program should take errors into account, so this solution is unacceptable.
|
|
|
|
The best solution is in this case is *error propagation* using the question mark =?= operator. It works similarly to =.unwrap()=, but instead of panicking on the =Err(E)= case, it returns =Err(E)= from the function. This lets you quickly unwrap results without convoluted =match= statements.
|
|
|
|
This lets you convert this:
|
|
|
|
#+begin_src rust
|
|
let x = match get_result() {
|
|
Ok(value) => value,
|
|
Err(error) => return Err(error),
|
|
};
|
|
#+end_src
|
|
|
|
Into this:
|
|
|
|
#+begin_src rust
|
|
let x = get_result()?;
|
|
#+end_src
|