Wrapping errors

[simonsan]

A small read how to wrap errors when creating a library: https://web.archive.org/web/20210125225615/https://edgarluque.com/blog/wrapping-errors-in-rust

Do you think it makes sense to include wrapping errors as a pattern? I would ask the initial author if he wants to contribute his work or wants to write an article about this.

[fade2black]

@simonsan I also looked through a couple of frameworks written in Rust. Many of them use thiserror.

[pickfire]

thiserror (library) and anyhow (application) is what I mostly use.

[MarcoIeni]

thiserror (library) and anyhow (application) is what I mostly use.

Yes, me too.

If you take a look at the last paragraph he mentions thiserror as a way to avoid all the code of the previous sections. So yeah, maybe we should close this issue.

Maybe we should create an "error handling" idiom where we discuss about thiserror and anyhow?

[simonsan]

failure, anyhow, eyre - Crates come and go, get superseded by others and I think it's viable to know how to wrap your own errors in a library not necessarily depending on a crate for this.

From one viewpoint a crate can help "avoid" this, with the cost of adding another dependency that needs to be maintained by people long-term. I don't think we should close this, as I think this is a basis for every library if you don't want to rely on many dependencies.

I feel all these crates are mentionable in the See Also section, but shouldn't replace the knowledge about how wrapping your errors work in a library.

[MarcoIeni]

I disagree. I feel like not using thiserror and writing all that boilerplate is an anti pattern 😅

[simonsan]

https://wiki.alopex.li/RustStarterKit2020

I feel this guy in that case. :( So the problem I see if we write about specific crates, that we will just rewrite an article every year and that's not really what I feel is needed for example if you write a small library. And if we state, that there are currently this and that crates "in", that avoid some boilerplate, people can still chose between writing something on their own that probably works the same way in 5 years, or they use crates for this purpose. Think we should try giving people exactly input on that topic, to let them chose easier what is a good option for them.

[MarcoIeni]

Yeah, I see what you mean but I don't share that point of view, because thiserror is not exposed to external users of your library (on the contrary of anyhow for example), because it is translated into standard rust types. So you can continue to use thiserror for all the lifetime of your library without any problem (it is at version 1).

Anyway, showing how all these libraries works under the hood might be really nice. So following the same approach of the article might be the right way to explain this topic. I.e. first showing how you would do it by hand and than saying that in order to avoid all the boilerplate you can use thiserror.

So feel free to contact the author :)