Error Handling in a Correctness-Critical Rust Project
Let’s begin with two excerpts from the paper Simple Testing Can Prevent Most Critical Failures: An Analysis of Production Failures in Distributed Data-intensive Systems
These stats haunt me. They cause me to frequently ask myself “how can I design my systems to increase the chances that errors will be handled correctly?”
We use Result to represent an operation which may succeed or fail. We tend not to write many functions that accept Results as arguments, because a Result fundamentally represents uncertainty about whether an operation will succeed or not. By the time we have an actual Result object, we no longer have uncertainty about whether the operation was successful or not. We know what happened. Results tend to flow backwards to callers, rather than forwards into newly called functions.
Error handling may begin once it is known that an error has occurred. However, we often do not wish to handle an error at the exact point in which it is known to have happened. Imagine this code:
