Add `thiserror::Error` proc macro to `std::prelude`

language design
7

I would also like to eventually have better support in the standard library for errors, but I'm also worried about getting stuck with a local maximum. I feel that a first step would be to clarify the API guidelines for errors as I feel that there's still so much fragmentation across the ecossytem.

The few issues that I encounter regularly are:

  1. Formatting error chains. Despite source being there for a very long time, the API guideline PR to recommend using source instead of embedding the message of the cause has been stuck for years, and we still get tons of new libs even today repeating the mistake of including the source message (e.g. I like @joshka 's proposition, but even their message makes the mistake). I assume that it stems from the fact that there's still nothing in the standard lib to print an error chain. I use a helper lib, but it's still a bit surprising how hard it is to display an error chain.
  2. Poor guidance on how to bubble up errors. Using thiserror, the simplest way to handle it is through Error enums, but @epage is 100% right that it leaks impl details. Another popular style is to have an Error struct, with a Kind enum for the possible causes (std::io::Error is the most famous case). This is nice, but still a bit cumbersome to implement. There's also no guideline to help libs picking the best style.
  3. Despite the saying that "errors are regular values in Rust", they are still second class citizens in practice. Most of them are lacking base traits such as Eq, Clone, serde::Serialize which makes it very inconvenient to do anything else than just printing them.
  4. Per-lib or per-module errors are common but make error recovery very hard to implement since the type system becomes useless: all the error causes apply to all the functions, there's no granularity.

I would appreciate some improvements to the API guidelines for errors first, before enshrining a style in the std lib. I agree however that help to derive Display would be a good start. As another data-point, derive_more is also a lib supporting Display derives. Regarding displaydoc, I feel that it's a cool trick and we used it a lot at work, but in practice it turned out to be anti-pattern to conflate formatting with documentation (the doc is bad, with formatting elements mixed in).

8 Likes