4 ms·
Just to point out for other readers, nowadays to make a custom error type you just need : - an enum (or struct) - its Display implementation - its Error impl
by jrimbault 6y ago
Just to point out for other readers, nowadays to make a custom error type you just need :
- an enum (or struct)
- its Display implementation
- its Error implementation, now just one function
And a few `impl From<OtherError> for MyError` to make the try? operator work.
For a library it's really not that much work. And even that can be simplified further to a few derive macros with another library : thiserror.
- asdkhadsj 6y agoTo 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