Crates.io | terrors |
lib.rs | terrors |
version | 0.3.0 |
source | src |
created_at | 2024-03-30 14:04:39.857815 |
updated_at | 2024-04-06 17:48:11.846531 |
description | ergonomic and precise error handling built atop type-level set arithmetic |
homepage | |
repository | https://github.com/komora-io/terrors |
max_upload_size | |
id | 1191108 |
size | 60,426 |
Handling errors means taking a set of possible error types, removing the ones that are locally addressible, and then if the set of errors is not within those local concerns, propagating the remainder to a caller. The caller should not receive the local errors of the callee.
terrors::OneOf
solves this by making precise sets of possible errors:
use terrors::OneOf;
let one_of_3: OneOf<(String, u32, Vec<u8>)> = OneOf::new(5);
let narrowed_res: Result<u32, OneOf<(String, Vec<u8>)>> =
one_of_3.narrow();
assert_eq!(5, narrowed_res.unwrap());
OneOf can also be broadened to a superset, checked at compile-time.
use terrors::OneOf;
struct Timeout;
struct AllocationFailure;
struct RetriesExhausted;
fn allocate_box() -> Result<Box<u8>, OneOf<(AllocationFailure,)>> {
Err(AllocationFailure.into())
}
fn send() -> Result<(), OneOf<(Timeout,)>> {
Err(Timeout.into())
}
fn allocate_and_send() -> Result<(), OneOf<(AllocationFailure, Timeout)>> {
let boxed_byte: Box<u8> = allocate_box().map_err(OneOf::broaden)?;
send().map_err(OneOf::broaden)?;
Ok(())
}
fn retry() -> Result<(), OneOf<(AllocationFailure, RetriesExhausted)>> {
for _ in 0..3 {
let Err(err) = allocate_and_send() else {
return Ok(());
};
// keep retrying if we have a Timeout,
// but punt allocation issues to caller.
match err.narrow::<Timeout, _>() {
Ok(_timeout) => {},
Err(one_of_others) => return Err(one_of_others.broaden()),
}
}
Err(OneOf::new(RetriesExhausted))
}
OneOf
also implements Clone
, Debug
, Display
, and/or std::error::Error
if all types in the type set do as well:
use std::error::Error;
use std::io;
use terrors::OneOf;
let o_1: OneOf<(u32, String)> = OneOf::new(5_u32);
// Debug is implemented if all types in the type set implement Debug
dbg!(&o_1);
// Display is implemented if all types in the type set implement Display
println!("{}", o_1);
let cloned = o_1.clone();
type E = io::Error;
let e = io::Error::new(io::ErrorKind::Other, "wuaaaaahhhzzaaaaaaaa");
let o_2: OneOf<(E,)> = OneOf::new(e);
// std::error::Error is implemented if all types in the type set implement it
dbg!(o_2.description());
OneOf can also be turned into an owned or referenced enum form:
use terrors::{OneOf, E2};
let o_1: OneOf<(u32, String)> = OneOf::new(5_u32);
match o_1.as_enum() {
E2::A(u) => {
println!("handling reference {u}: u32")
}
E2::B(s) => {
println!("handling reference {s}: String")
}
}
match o_1.to_enum() {
E2::A(u) => {
println!("handling owned {u}: u32")
}
E2::B(s) => {
println!("handling owned {s}: String")
}
}
The paper Simple Testing Can Prevent Most Critical Failures: An Analysis of Production Failures in Distributed Data-intensive Systems is goldmine of fascinating statistics that illuminate the software patterns that tend to correspond to system failures. This is one of my favorites:
almost all (92%) of the catastrophic system failures
are the result of incorrect handling of non-fatal errors
explicitly signaled in software.
Our systems are falling over because we aren't handling our errors. We're doing fine when it comes to signalling their existence, but we need to actually handle them.
When we write Rust, we tend to encounter a variety of different error types. Sometimes we need to put multiple possible errors into a container that is then returned from a function, where the caller or a transitive caller is expected to handle the specific problem that arose.
As we grow a codebase, more of these situations pop up. While it's not so much effort to write custom enums in one or two places that hold the precise set of possible errors, most people resort to one of two strategies for minimizing the effort that goes into propagating their error types:
As the number of different source error types that these error containers hold increases, the amount of information that the container communicates to people who encounter it decreases. It becomes increasingly unclear what the error container actually holds. As the precision of the type goes down, so does a human's ability to reason about where the appropriate place is to handle any particular concern within it.
We have to increase the precision in our error types.
People don't write a precise enum for every function that may only return some subset of errors because we would end up with a ton of small enum types that only get used in one or two places. This is the pain that drives people to using overly-broad error enums or overly-smooth boxed dynamic error traits, reducing their ability to handle their errors.
This crate is built around OneOf
, which functions as
a form of anonymous enum that can be narrowed in ways
that may be familiar for users of TypeScript etc...
Our error containers need to get smaller as individual
errors are peeled off and handled, leaving the reduced
remainder of possible error types if the local concerns
are not present.
The cool thing about it is that it is built on top of a type-level heterogenous set of possible error types, where there's only one actual value among the different possibilities.
Rather than having a giant ball of mud enum or boxed trait object that is never clear what it actually contains, causing you to never handle individual concerns from, the idea of this is that you can have a minimized set of actual error types that may thread through the stack.
The nice thing about this type-level set of possibilities is that any specific type can be peeled off while narrowing the rest of the types if the narrowing fails. Both narrowing and broadening are based on compile-time error type set checking.
Type-level programming is something that I have tried hard to avoid for most of my career due to confusing error messages resulting from compilation errors. These complex type checking failures produce errors that are challenging to reason about, and can often take several minutes to understand.
I have tried hard to avoid exposing users of terrors
to too many
of the sharp edges in the underlying type machinery, but it is likely
that if the source and destination type sets do not satisfy the SupersetOf
trait in the right direction depending on whether narrow
or
broaden
is being called, that the error will not be particularly
pleasant to read. Just know that errors pretty much always mean
that the superset relationship does not hold as required.
Going forward, I believe most of the required traits can be implemented
in ways that expose users to errors that look more like (A, B) does not implement SupersetOf<(C, D), _>
instead of Cons<A, Cons<B, End>> does not implement SupersetOf<Cons<C, Cons<D, End>>>
by leaning into the
bidirectional type mapping that exists between the heterogenous type
set Cons
chains and more human-friendly type tuples.
Much of the fancy type-level logic for reasoning about sets of error types
was directly inspired by frunk.
I had been wondering for years about the feasibility of a data structure
like OneOf
, and had often assumed it was impossible, until I finally
had an extended weekend to give it a deep dive. After many false starts,
I finally came across an article written by
lloydmeta (the author of frunk) about how
frunk handles several related concerns in the context of a heterogenous
list structure. Despite having used Rust for over 10 years, that article
taught me a huge amount about how the language's type system can be
used in interesting ways that addressed very practical needs. In particular,
the general perspective in that blog post about how you can implement
traits in a recursive way that is familiar from other functional languages
was the missing primitive for working with Rust that I had not realized
was possible for my first decade with the language. Thank you very
much for creating frunk and telling the world about how you did it!