Rust: Structuring and handling errors in 2020 (2020) | Hacker News Reader

Rust: Structuring and handling errors in 2020 (2020)

nick.groenen.me

147 pointsarm14 comments

Worth noting that this blog post was written before the official Error Handling Project Group got going. The Group aims to regularize best practice and bring it into the standard library.

https://blog.rust-lang.org/inside-rust/2020/11/23/What-the-e...

(Disclaimer: I'm not involved with this group in any way.)

This advice mostly makes sense to me now, but coming in as a newbie, I didn't know what either `Box` or `dyn` meant, and I didn't want to just cargo-cult copy-paste. A newcomer to the language has to deal with error handling right away, long before you need to know about either `Box` or `dyn`.

I sort of wish there was some official `Outcome` type defined as an alias of `Result<T, Box<dyn Error>>`:

   fn main() -> OutCome<()> {
       foo()?;
       Ok(())
   }

And then all the crates that offer their own `Result` types would have offered an `Outcome` insteaad: `io::Outcome`, `fmt::Outcome`, etc.

It's not that big a deal, eventually we'll all struggle through — but `Box<dyn Error>` is a bit confusing at first.

You might like 'anyhow': https://github.com/dtolnay/anyhow

Yeah `anyhow` is basically `Result<T, Box<dyn Error>>` but ergonomic.

> I sort of wish there was some official `Outcome` type defined as an alias of `Result<T, Box<dyn Error>>`

Would it be as easy as

type OutCome<T> = Result<T, Box<dyn Error>>;

Yes! But...

1) If I type that line myself, I want to know what `Box<dyn Error>` means.

2) For an audience of mixed levels of Rust expertise, the `Box<dyn Error>` idiom is on average clearer, because the more experienced Rustaceans will have seen it before while `Outcome` will be unfamiliar and in need of explanation.

I thought about publishing a crate with just that one line, but there's already a slew of other similar solutions out there (anyhow, any-error, etc...). There's not that much to gain.

I just think it's worth pointing out that it's weird to require newbies to understand `Box` and `dyn` in order to handle errors.

Another crate to mention - eyre and color-eyre, basically a port of anyhow but a few bells and whistles, and an awesome colored error report formatter.

https://github.com/yaahc/color-eyre

I use a similar method for error handing, using the derive_more crate to avoid the boilerplate. I really wish that the error messages for standard library operations, like opening a file, were more descriptive. It's a pain to have to wrap the error with the filename ever time you do an IO operation.

On the off-chance you didn't know: the `fs-err` crate is a drop-in replacement for `std::fs` that provides more friendly error messages.

https://docs.rs/fs-err

I didn't know, thanks!

Thanks for this post. It’s been a while since I wrote a lot of rust code that needed more error handling. I used the error-chain crate like two years ago and was never really satisfied. The macro construct felt weird. I also split my application into binary and library part. I will check out these two crates for my next project because the code looked really nice. Except maybe the map_err cases. I dislike the need to manually wrap errors around. The error-chain crate had default into implementations and chain functions for the result type. But honestly I never got around to understand when to use what.

[error-chain]: https://crates.io/crates/error-chain

Funny to see this here, as I just referenced this for my toy project (via a Google search). If you're toying with Rust, `anyhow` is what you want (the blog post describes what to do if you want to go beyond printing errors as strings).

Reply on news.ycombinator.com