5 ms·
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
by matklad 7y ago
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 7y agoThe good thing with this_error is that it's just a custom derive on vanilla std::error::Error.
- Arnavion 7y agoI 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 7y agoThis 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.