Error-chain is no longer maintained

announcements
8

At the end, my blog post says this:

If you’re writing a library and your code can produce errors, define your own error type and implement the std::error::Error trait. Where appropriate, implement From to make both your library code and the caller’s code easier to write.

The blog post contains at least a few examples of this.

Today, I would probably not use any error handling helper library for a library. Generally, I do not think defining your own errors requires that much boiler plate. Defining the error variants themselves, along with how to convert them and how to show them, are all important aspects of your public API. (And perhaps more importantly, paying careful attention to this is crucial for choosing what exactly you expose. It can be very easy to accidentally incur a public dependency on another library by re-exporting one of its errors or exposing a From impl. It may instead make sense to not export such errors.) The "boiler plate" part of it is really the bits and pieces around it, e.g., writing out the impl From<...> for ... {}, writing out the impl fmt::Display for ... { } along with the corresponding match expressions.

I've done this many times myself. Here are some of them: (Some of this code still contains impls of cause or description, but you can drop the latter, and should implement source instead today, if pertinent.)

5 Likes