Hacker News Reader

Comment by bluejekyll | Hacker News Reader

This is a good intro, while it mentions `thiserror`, I personally can’t recommend this enough. For anyone building a library, the ability to wrap underlying errors and generate a From implementation quickly for them (converts from source error to target) is it’s super power. It also takes a simple error string to create the Display implementation. It does all of this and generates code and types that are consistent with the std library.

It’s good to understand the error mechanics, but don’t wast time writing custom errors, just use `thiserror`.

View on HN

If you're writing internal libraries or libraries that are otherwise already using proc macros, sure, but I don't otherwise agree with this advice personally. It takes me maybe a couple of extra minutes to write out the error type and associated code. In exchange, every single compilation of my library will be faster as a result.

To be clear, 'thiserror' is great and it would probably fit well inside of std. Then that extra compilation time I'm complaining about could be avoided.

I don't disagree with this... but is there anything wrong with recommending `thiserror` by default, especially for less experienced Rustaceans? It's fairly sane, encourages "good" error design. I wish there'd been something like it when I started.

And moving forwards, you could a) still write out the error type and associated code to replace `thiserror` fairly easily, or b) possibly benefit from any work being done to speed up proc macros in the future. So I feel like recommending it as a default is still the best option?

That's a harder question to answer IMO with less clear trade offs. It gets into pedagogical style. I think for me, it depends on what's being done, but I can see how it might be a decent recommendation by default. I think you can afford a sentence about its cost though, so I'd suggest including that. When in doubt, present the trade off.

It might be worth doing this on a stable crate, that doesn’t have a lot of dependencies.

For me, when there are so many it’s a trade-off. Sure, hand coding it isn’t hard, maybe you can even build a macro_rules that can deal with most of the down the middle cases, but ultimately thiserror makes development faster and simpler.

It’s always something that can be optimized away pretty easily later.

Yeah I guess I've just never been in a situation where making the definition of error type take ~1 minute vs ~5 minutes (for example) was a difference maker. Firstly because the frequency of defining new error types is so low. And secondly because it often takes me longer to even figure out what the error type should look like. The savings from 'thiserror' is basically just in the noise for me.

I would use it if it were in 'std' though. I would also use it in a project that already had a lot of dependencies, since it's likely such a project is probably already bringing in the proc-macro stuff.

For years, there have been definitive error crates, each with it's own monstrocity of macro to generate more code, and for every new one there have been painful migrations for codebases of any significant size. Writing out the error types manually isn't actually that difficult.

For library code thiserror has been by far the best experience, sure I can write out the error code manually but why would I waste my time pumping out boiler plate.

The combination of thiserror and anyhow have been my go to for nearly 3 years without issue.

thiserror is quite a lot lighter than most of the prior ones have been. It also has less magic than they tended to, which is nice. It just does what it says it's gonna do mostly.

Honestly I think thiserror and anyhow strike the right balances that I think they could be candidates for stdlib inclusion, and then might be more optimized.

> and for every new one there have been painful migrations for codebases of any significant size

Why did you migrate though? At work, we're still using error_chain for the oldest library we have since the ergonomics of the library isn't an issue for these stable-ish libs. If what you already have works, just don't migrate. It's not like there's likely hidden segfaults or memory vulns waiting there…

> It's not like there's likely hidden segfaults or memory vulns waiting there…

It's funny you mention that, because the now-deprecated 'failure' crate has such a memory-safety vulnerability: https://github.com/rust-lang-deprecated/failure/issues/336

Granted, consuming code is only vulnerable if they opt-in to implementing a provided trait method that most people should never ever need to implement. But I would still try to eliminate 'failure' from my dependency graph if possible (and I recently submitted PRs to two dependencies I was using to remove 'failure' from their dependencies).

Seconded! It also helps in my code that I can see all the things that can go wrong for a given module. Sure, this isn't unique to "thiserror" because you can do this with any enum, but it's much cleaner while being sensible and explicit.

The only problem with thiserror is the lack of no_std tho, which leads me to use snafu instead

Reply on news.ycombinator.com