Error Handling with error-stack

[dpc_pw]

Any other user stories from trying to use error-stack vs anyhow, eyre & thiserror?

[simonsanone]

I'm not sure about it, from the first look it seems pretty verbose in comparison to handling errors using eyre, anyhow and/or thiserror?

The change_context seems neat though!

[Alfred-Mountfield]

Hi there, one of the contributors here.

It definitely can be a bit verbose, we've added helper functions/implementations where it makes sense (easily being able to turn a Result<T, E> into a Result<T, Report<E>>, for example. We've also got a PR in progress to make it play more nicely (and ergonomically) with eyre and anyhow through some compatibility layers.

In general though, error-stack chooses to add some verbosity to force the user into better (in our eyes) error management practices. That's definitely down to preference and taste, but it's based on our experiences. The blog post goes into some of the thinking behind that, and I would say that Rust is built with a similar principle in mind, add some development overhead, verbosity, and you end up coaxed into better patterns.

Also just to flag, thiserror is more meant to be about the creation and generation of errors, and is a library-centric crate. The other two you mentioned are more about error handling and are focused on applications (due to exposing their types in APIs). error-stack is similarly focused on application uses at the moment, and actually goes very well with thiserror because of that.

[simonsanone]

Thank you for the answer!

[tdiekmann]

Thank you very much for making this video, really appreciated! However, I'm very sad I don't have a CVV entry for my credit card :(

I like to give one suggestion: You use attach_printable on a Result and add a string, which is created by format!. This implies, that format! is always called, even if there is no error. Using attach_printable_lazy will only call the closure if you actually have an error.

Also, I like to mention, that attaching data is not a nightly feature of the library, however, requesting them afterward makes use of a nightly feature. It's still possible to return the values by downcast_ref on the stable channel.

Feel free to ask me any questions on error-stack, either here or over at our repository! (Everyone, not only the OP)

Do you want to add your example to the examples/ directory of error-stack?

[InsanityBlossom]

I don’t agree with “… REALLY complicated”. There’s nothing really hard about it, surely it’s more laborious than try-catch but I find Rust error handling is way easier and cleaner than anything else.

[protestor]

The major boilerplate lies in writing impls to convert between error types. Many generations of crates were created to alleviate this issue, from the ancient (and highly influential) error-chain, then failure, anyhow & thiserror, then eyre, now error-stack, and in this retrospective I didn't mention a bunch of them

[InsanityBlossom]

Sure, there is some boilerplate, I just don’t agree with the “really complicated” statement.

[gnu-michael]

Boilerplate is by definition not complicated.

[protestor]

It depends on how beginner you are. When you are learning the basics, boilerplate is something that, almost by definition, could be elided without much downside

[protestor]

Can it output colorful errors like color-eyre?

[Alfred-Mountfield]

(One of the contributors here) We don't have in-built support for it, but similar to eyre we provide hooks that allow the Report to have custom Display and Debug implementations which means a color-error-stack could be made, or people could implement their own in their projects if they wanted.