4 ms·

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 err

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`.

eptcyka 4y ago
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.
- tempest_ 4y ago
  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.
- stormbrew 4y ago
  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.
- littlestymaar 4y ago
  > 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…
  - kelnos 4y ago
    > 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 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).
burntsushi 4y ago
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.
- guitarbill 4y ago
  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?
  - burntsushi 4y ago
    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.
    - bluejekyll 4y ago
      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.
      - 4y ago
lytedev 4y ago
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.
stevefan1999 4y ago
The only problem with thiserror is the lack of no_std tho, which leads me to use snafu instead

eptcyka 4y ago

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.

tempest_ 4y ago
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.
stormbrew 4y ago
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.
littlestymaar 4y ago
> 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…
- kelnos 4y ago
  > 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 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).

burntsushi 4y ago

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.

guitarbill 4y ago
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?
- burntsushi 4y ago
  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.
  - bluejekyll 4y ago
    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.
    - 4y ago

lytedev 4y ago

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.

stevefan1999 4y ago

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