After being out of the loop (not following this-week-in-rust as closely as I used to) for several months, I have the opportunity of starting a small/medium binary Rust project at work. I choose Rust for its safety, and the simplicity of delivering a binary with a low footprint. Before I start typin…

Failure's #[derive(Fail)] gives you the opportunity to chain the original Error with the #[cause] attribute. Your top-level error handler can then print the entire chain of errors by iterating Fail::iter_causes . For example, here is my top-level error handler in cargo-n64. You only need one! The ? …

This sounds amazing! I'm usually reluctant to try new crates/libraries (like Failure), because of a fear of me jumping off on a tangent, but this seems pretty useful, even if it takes some time to get used to. And yeah, it doesn't seem to logical to include it in a library, where the user should tak…

io::Error is only one case where I'm doing error handling (and any non-trivial app would handle various errors of all sorts). For example, I have to parse JSON and ELF files; those parsers have their own error variants. I execute an external command (cargo) and it can fail in many ways, ... Basicall…

Failure's getting kind of old at this point. I've been using it for a little more than a year. If it makes you feel any better, we're using it in all our crates and projects at System76. It simply takes care of every possible error handling strategy without the majority of the boilerplate required t…

(I really shouldn't try to make jokes on these pages, should I?)

[image] OptimisticPeach: I prefer to use a direct panic when the error is application breaking... This is actually the point of panicking! There is only sense in returning a Result when the error reported is meaningful information that the caller can use. For more on this philosophy, see: Jo…

The best thing for the ergonomics of error handling is the ? (question mark operator) . Until the RFC is released to enable try { ... } blocks you may use the crate ::candy and its catch! macro to already enjoy the nice error handling: #[macro_use(catch)] extern crate candy; // or, with the 2018 ed…

[image] chen: For mere mortals, what should I expect to happen in the near/mid future? Is there any blog post I can read about it? This is not authoritative but according to this reddit thread The future of std::error::Error was kinda decided in RFC 2504

If you're making a library, don't use the failure crate. Instead: define an enum that covers meaningful error cases for your library, implement std::error::Error for that enum. And that's it. This is going to be fast/cheap (no heap allocation on error), and precise and easy to use (instead of an …

These days I tend to use std::error::Error for everything. If you want a generic error type and you don't care about what's in it (apart from being able to print an error chain) use Box<dyn std::error::Error + 'static> with Send and Sync if you need. That way you can even recover the original type i…

The state of error handling in the 2018 edition

help

ExpHP August 7, 2019, 7:01pm 25

Yes, it enables conversion to Box<dyn std::error::Error>.

Topic		Replies	Views
Error-chain is no longer maintained announcements	18	9682	May 1, 2019
Do you agree with my opinions on error handling?	5	924	December 28, 2018
Announcing Failure announcements	25	7976	December 20, 2017
An "heretic's" view of Rust error-handling	121	2089	April 30, 2026
Rust Error Handling help	13	1639	February 19, 2022

The state of error handling in the 2018 edition

Related topics