undefined | Better HN

0 pointsjrimbault5y ago0 comments

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.

0 comments

asdkhadsj5y 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)

JeanMertz5y ago

Even 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 [2]: https://crates.io/crates/displaydoc [3]: https://crates.io/crates/anyhow

j / k navigate · click thread line to collapse