Error Handling

[FintanH]

This PR proposes how to make decisions around error handling in Rust and which packages to use for making our lives easier.

[kim]

I think thiserror is what I actually wanted for librad. A few questions, though:

• why is anyhow better suited to work in conjunction with thiserror?
• I'm not sure about the assertion point: is this about being able to write assert!(matches!(...)) or?
• I think it could be spelled out a bit more concretely what the recommendations / guidelines are for using this combo of libraries. To me, errors-as-values always boils down to the basic question: do I want the caller to implement control flow based on the error variant or not? In the latter case, how would I express this with anyhow + thiserror? Is the recommendation to use Box<dyn Error> (or a generic Error(String) variant) in libraries, and anyhow::Error in application code? What about unifying a Box<dyn Error> at a higher level? MyError::DunnoButItBroke(Box<dyn Error>)?

[FintanH]

@kim: Thanks for the feedback! I'll address the 3rd point by fleshing out the recommendation section more. Regarding the other two points, here's my thoughts.

why is anyhow better suited to work in conjunction with thiserror?

In reality, any library that has interoperability with the std::Error trait will work with thiserror, since this is what the library provides as well as the display stuff, "This library provides a convenient derive macro for the standard library's std::error::Error trait.". So, failure will work fine since it provides AsFail.

However, I think something to keep in mind is that thiserror and anyhow are developed by the same author so they're meant to complement each other.

Otherwise, it's down to which set of functionalities we would prefer and anyhow seems to squeeze out more in this area.

What do you think? Also let me know if any of this info is useful for the proposal proper.

I'm not sure about the assertion point: is this about being able to write assert!(matches!(...)) or?

The assertion point is about the macros used for early return syntax rather than assert!. They both have ensure!and bail!, but anyhow allows you to return an enum variant, example in the docs

[xla]

Sick first draft. Left a bunch of suggestions for typos and a general question about the understanding of Option.

I agree with @kim - examples of the recomnended stack, one for a lib and one for an app would help a lot.

[garbados]

Looks good to me so far -- I third the point that code examples of using the suggested stack in our context would be helpful.

[geigerzaehler]

Great work! Nothing to add

[kim]

There is also #[non_exhaustive], which I think is also a good recommendation: always force library consumers to be prepared for new variants / fields.

[FintanH]

Oh interesting 🤔 I'll add this to the recommendation.

[kim]

Hm ok. I think I would in practice have an internal error enum, and unify that at a higher level in a variant ContentsOfSausage(Box<dyn Error>). Because, with this solution you would end up with a lot of standalone structs only for the purpose of hiding the underlying error, or no?

[FintanH]

Well the struct can hide a private enum of opaque errors. So whatever is in the opaque struct is up to you. Whether it's dyn Error or something else, all it needs is the Error derivation.

My point for having this opaque struct method is to still allow the library to handle the errors if it thinks it can, otherwise it'll eventually become a String.

Would you agree?

[kim]

Yeah I agree, but I suspect that I’d be too lazy to exercise this diligently XD.

[FintanH]

lol, we can always amend ;)

[NunoAlexandre]

Fine write-up, @FintanH ✌️

I would recommend you run this file through grammarly.com, mostly to add missing commas that make the text a bit harder to read at times.

[NunoAlexandre]

unless you parse, but please don't

this!

[xla]

📚 📀 🛎 ⌚️

[FintanH]

Thanks, everybody ❤️ 🌱