3 ms·

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

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

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