[steveklabnik]

https://blog.yoshuawuyts.com/error-handling-survey/ is a good summary of what's out there.

I think current rough consensus is anyhow/thiserr depending on if you're writing an application or library. I haven't actually used them myself, though. You don't have to keep up with the cool new libraries.

[matklad]

Agree that there’s consensus on anyhow for applications, but I think many folks now prefer vanilla std::error::Error for libraries (which itself got better as a result of all the experiments in the ecosystem).

[littlestymaar]

The good thing with this_error is that it's just a custom derive on vanilla std::error::Error.

[Arnavion]

I used to maintain a custom derive crate for errors before failure came out, but these days I just use manual impls of `std::error::Error` for libraries and `Box<dyn std::error::Error>` for applications. I can't be bothered to keep up with the Rust error-library-du-jour game, even if it so happens that today's darling custom derive (thiserror) would emit the same `std::error::Error` impl that I write by hand.

Manual impls may be tedious to write, but they change rarely after they've been written, enough that the con of adding one more dependency that may go away tomorrow outweighs the con of writing them manually.

[jfkebwjsbx]

This matches my experience as well. I want to write code that works for years (dependencies make this hard) and is understood by everyone. So explicit is best.