Move away from error_chain. Failure, Anyhow, thiserror ?

[spazm]

Previously, the advice was to go from error_chain to failure, but now failure is also deprecated.

Our use of errors{} in the error_chain! macro uses description and display to generate the errors, which is now deprecated, preferring impl Display. That's way more verbose, so there must be a way to generate/derive our errors cleanly. The error_chain documentation has not been updated to describe how to use the new syntax.

failure - a new error management story

Notice: failure is deprecated. If you liked failure's API, consider using:

Anyhow is a good replacement for failure::Error.
thiserror is a good, near drop-in replacement for #[derive(Fail)]

[spazm]

Some recent (late 2019) articles on error handling. The first is the most comprehensive.

1. A survey of 9 crates: https://blog.yoshuawuyts.com/error-handling-survey
2. https://www.ncameron.org/blog/rust-in-2020-one-more-thing/
3. https://lukaskalbertodt.github.io/2019/11/14/thoughts-on-error-handling-in-rust.html

Related tickets:

1. Source iterators: Tracking issue for error source iterators rust-lang/rust#58520
2. Fix the Error Trait: Tracking issue for RFC 2504, "Fix the Error trait" rust-lang/rust#53487
3. stabilization for Backtrace (portion of 2): Stabilize the backtrace feature. rust-lang/rust#72981

[spazm]

Article that builds and references the survey.

https://nick.groenen.me/posts/rust-error-handling/

Includes a trivial app and split into main.rs and lib.rs and with anyhow and thiserror respectively.

• thiserror for the library parts, the parts that want public error types for consumers.
• anyhow for applications that want to match and format errors. Tagging errors with anyhow #context.