Discussion: Error handling alternatives

[aphelionz]

Not sure how actionable this is, but I'd like to survey the community and gather ideas on how to make this better in Rust IPFS.

Also, note that as other commits and refactors take place, the context and options here might change, so check in frequently.

[vmx]

I don't understand what you mean. Is this in regards on how which errors Rust IPFS should have/expose, or about which libraries to use?

[aphelionz]

I think this is a broad topic, so... both. I just want to capture all of the feedback and ideas here.

[vmx]

Then I have an opinion about libraries. I would like to stick with thiserror and anyhow. Though sticking to thiserror as much as possible (especially for libraries) as it doesn't bleed into the public API (as anyhow does).

[dvc94ch]

That makes sense. But should there be an error per public function or an error per crate? But yes, we should remove the dependency on anyhow.

[koivunej]

I think the error strategy of a library should cater to for those errors being able (in the order of importance -- I am quite split on the importance ordering of 1 and 2):

1. to help the caller understand the situation (we enjoy helpful errors from rustc, why not crates)
2. to allow matching on meaningful subset of errors which happened vs. big opaque crate::Error type which is always returned (this can be very ok for smaller crates but perhaps not for rust-ipfs)
3. to be simple to write for the crate developers

First one is about library user quickly understanding whats going on. I of course think about finding errors in logs but during development this is important as well.

I think thiserror or even better, just using plain enum might be the best way overall, with some added help from derive_more if really needed. Now that std::error::Error has a default for fn description(&self) implementing the trait is quite straightforward.

The current situation with anyhow pretty much focuses on the third point, which I think is the least important.

[koivunej]

Having been cooking this up for a while, been writing a ton of boilerplate in ipfs-unixfs and ipfs-http around errors. Having also done a bit of thiserror I feel the plain implementation of traits is natural as there is no new syntax which needs to be learned and also no surprises. Downside is of course that one needs to remember to do a lot of stuff.