Hacker News Reader

Comment by eptcyka | Hacker News Reader

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.

View on HN

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

Reply on news.ycombinator.com