Error handling in Rust

The article expressly suggests not wrapping/embedding those errors but instead putting the errors into context. That suggestions starts with the sentence "Define errors in terms of the problem, not a solution" and explicitly shows a wrapping as an anti-pattern then lays out the better solution. Note that the author's solution serializes the underlying error in some cases to avoid leaking it as a dependency.

You can use ? when you implement From (to get an automatic Into) which which can be as easy as a #[from] annotation with thiserror. You can manually implement From instead of inlining the map_err if you so choose. Then you are only ever using map_err to pass additional contextual information. You usually end up using ? after map_err or directly returning the result.

"?" call "into()" automatically, which covers simple wrapping.

It’s not just syntax, there are semantic problems.

Like, function 1 fails for reason A or B. Function 2 fails for A or C. You call both functions. How do you pattern match on reason A, in the result of your function?

In Go, there’s a somewhat simple pattern for this, which is errors.Is().

The difference is that Java does not have polymorphism for exception sets (I think? certainly it didn’t for anything back then), so you couldn’t even type e.g. a callback-invoking function properly. Otherwise, yes, as well as the discussions about monad transformers in Haskell from 15 years ago. Effects are effects are effects.

Yeah, it's frustrating that there's no syntax for this. It could even be syntactic sugar; in this case if you had:

    type FooOrBarOrError = Foo | Bar | Error;

Then that could desugar to:

    enum FooOrBarOrError {
        Foo(Foo),
        Bar(Bar),
        Error(Error),
    }

And it could also implement From for you, so you can easily get a FooOrBarOrError from a Foo, Bar, or Error; as well as implementing Display, StdError, etc. if the components already implement them.

I actually wonder if you could implement this as a proc macro...

I don't, and I say this as a long-time user of C++'s std::variant and boost::variant, which are effectively union types.

Foo | Bar makes sense when Foo and Bar are logically similar and their primary difference is the difference in type. This is actually rather rare. One example would be a term in your favorite configuration markup language along the lines of JSON or YAML:

    type Term = String | List<String>;

or perhaps a fancier recursive one:

    type Term = String | Box<List<Term>>;

or however you want to spell it. Here a Term is something in the language, and there are two kinds of terms: string or lists.

But most of the time that I've wanted a sum type, I have a set of logical things that my type can represent, and each of those things has an associated type of the data they carry. Result types (success or error) are absolutely in that category. And doing this wrong can result in a mess. For example, if instead of Result, you have SuccessVal | Error, then the only way to distinguish success from error is to literally, or parametrically in a generic, spell out SuccessVal or Error. And there are nasty pathological cases, for example, what if you want a function that parses a string into an Error? You would want to write:

    fn parse_error(input_string: &str) -> Error | Error

Whoops!

    struct Ok<T>(T);
    struct Err<E>(E);

    fn parse_error(input_string: &str) -> Ok Error | Err (ErrorA | ErrorB | ErrorC...)

    enum Result<T, E>  {
        Ok(T),
        Err(E),
    }

    fn parse_error(input_string: &str) -> Result<Error, (ErrorA | ErrorB | ErrorC...)>

I've thought about this a good amount too because Typescript gets so much out of untagged unions but I think that with a language like Rust you get into a huge mess due to it messing up inference and also Rust _really_ wanting to know the size of a type most of the time.

    let mut x = 1
    x = false

is x a usize? a bool? a usize | bool?

    let mut x = if some_condition { 1 } else { false }

is x x a usize? a bool? a usize | bool?

One could make inference rules about never inserting unions without explicit intervention of user types. But then you get into (IMO) some messy things downstream of Rust's pervasive "everything is an expression" philosophy.

This is less of a problem in Typescript because you are, generally, much less likely to have conditionally typed expressions. There's a ternary operator, but things like `switch` are a statement.

So in production code Typescript, when presented with branching, will have a downstream explicit type to unify on. Not so much in Rust's extensive type chaining IMO. And then we start talking about Into/From and friends....

I don't really think that you want a rule like `(if cond { x: T } else { y: U}) : T | U` in general. You'll end up with _so many_ false negatives and type errors at a distance. But if you _don't_ have that rule, then I don't know how easily your error type unification would work.

    let mut x = 1
    x = false

    let mut x = if some_condition { 1 } else { false }

    let mut x = if some_condition { 1 } else { false }
    // bunch of code
    return f(x) // expected usize, got usize | bool

Look at Zig then, as it does exactly this. However you can’t carry any context and it’s also a problem.

I think this is a valid criticism, however I think the direction Rust went was better. It's easy in hindsight to say that the error handling system that emerged in ~2020-ish should have been baked in the library when the language was stabilized in 2015. However even in 2012 (when Go 1.0 was released), errors as values was a pretty novel idea among mainstream programming languages and Go has some warts that were baked into the language that they have now given up on fixing.

As a result, I find error handling in Go to be pretty cumbersome even though the language design has progressed to a point where it theoretically could be made much more ergonomic. You can imagine a world where instead of functions returning `(x, err)` they could return `Result[T]error` - an that would open up so many more monadic apis, similar to whats in Rust. But that future seems to be completely blocked off because of the error handling patterns that are now baked into the language.

There's no guarantee the Rust team would have landed on something particularly useful. Even the entire error trait, as released, is now deprecated. `thiserror`, the most popular error crate for libraries wasn't released until 2019.

> Overuse of macros is a symptom of missing language capabilities.

Agree.

> I think non-local flow control (i.e. exceptions) with automated causal chaining (like Python) is a good language design point

Stronly disagree: https://home.expurple.me/posts/rust-solves-the-issues-with-e...

> There should also have been an enforced "does not panic" annotation like noexcept in C++.

noexcept DOES NOT mean that the function can't throw an exception! It just means that, when it does, it aborts the program instead of unwinding into the calling function. Quoting cppreference [1]:

> Non-throwing functions are permitted to call potentially-throwing functions. Whenever an exception is thrown and the search for a handler encounters the outermost block of a non-throwing function, the function std::terminate is called

> And Drop implementations should not be allowed to panic. Ever.

Should `panic=abort` panics be allowed in Drop? They are effectively the same as std::process::exit. Do you want to mark and ban that too?

[1]: https://en.cppreference.com/w/cpp/language/noexcept_spec.htm...

> Rust should have had _only_ panics, and panic objects should have had rich contextual information, just like Java and Python.

It could have gone that way, but that would have “fattened” the runtime and overhead of many operations, making rust unsuitable for some low-overhead-needed contexts that it chose to target as use-cases. More directly: debug and stack info being tracked on each frame has a cost (as it does in Java and many others). So does reassembling that info by taking out locks and probing around the stack to reassemble a stack trace (C++). Whether you agree with Rust’s decision to try to serve those low-overhead niches or not, that (as I understand it) is a big part of the reason for why errors work the way they do.

> There should also have been an enforced "does not panic" annotation like noexcept in C++. And Drop implementations should not be allowed to panic.

I sometimes think that I’d really love “nopanic”. Then I consider everything that could panic (e.g. allocating) and I like it less. I think that heavy use of such a feature would lead to people just giving up and calling abort() in library code in order to be nopanic-compatible, which is an objectively worse outcome than what we have today.

Yup. And I’ve not seen that used in forever and it’s often considered a linting error because it is so nasty.

So maybe what I’m remembering about Rust was just seeing a possible but bad convention that’s not really used much.

Ok, that’s a valid point! Though there’s a trade-off there, right? If both bar and baz can not find a file, they’re both going to return their own FileNotFound error type. And then, if you care about handling files not being found somewhere up the stack, don’t you now have to care about two error types that both represent the same failure scenario?

   try {
       open file
       read some bytes
       read some more bytes
   }