6 ms·
To simplify even more, you don't actually need `Display` or `Error` impls. I use Error enums frequently without display or Error impls. Though, with better back
by asdkhadsj 6y ago
To simplify even more, you don't actually need `Display` or `Error` impls. I use Error enums frequently without display or Error impls. Though, with better backtrace support coming it'll be handy to have Error and the Backtrace related APIs implemented.
(Sidenote, I don't use `impl Error` because I never use `Box<dyn Error>`. Which isn't to say that's correct, just to say that I've never had the need to implement it)
- JeanMertz 6y agoEven though GP meant to highlight compiler error messages, I also have to take my hat off for the library/application error-handling story in Rust. Using a crate such as thiserror[1] combined with displaydoc[2] makes handling errors in a structured manner a great experience. I love how the error handling story has evolved over the last couple of years in Rust, and it really feels like we're entering into the final stretch of fine-tuning to get the best possible experience. And yes, anyhow[3] is also great, it serves a different purpose, but I frequently reach for all three crates. [1]: https://crates.io/crates/thiserror https://crates.io/crates/thiserror [2]: https://crates.io/crates/displaydoc https://crates.io/crates/displaydoc [3]: https://crates.io/crates/anyhow https://crates.io/crates/anyhow