Ergonomic errors in Rust: write fast, debug with ease, handle precisely
22 comments
·August 22, 2025TheCleric
catlifeonmars
Sometimes it’s nice to have one control flow mechanism rather than too. One could argue that traditional exceptions are more complicated with a their alternative control flow and syntax.
XorNot
I mean broadly that's my entire problem with errors as values: every implementation wastes a ton of syntax trying to make them like exceptions.
b_e_n_t_o_n
Go unironically gets this right - you just treat them like a normal value instead of trying to make them more "ergonomic".
MindSpunk
The common problems with exceptions isn’t the easy part of try/catch, it’s the execution model and “any function could throw” that causes most contention. Error values are logically simpler and fully document if and what errors the function can return. Checked exceptions solve that too, but in practice nobody used them even where available. And you still end up with hidden control flow with exceptions, the exceptional path through a function is syntactically invisible and difficult to audit without very strong language tooling.
marcianx
And also the issue with checked exceptions is that one can't be generic over the checked exception, at least in Java. So it's impossible to write out a universally useful function type that's strictly typed on the error. This definition of `ThrowingFunction` for Java [1] needs just have `throws Exception`, allowing just about anything to be thrown.
Most functional-inspired languages would just have a single `f: T -> Result<U, E>` interface, which supports both (1) a specific error type `E`, which can also be an uninhabited type (e.g. never type) for an infallible operation, and (2) where `U` can be the unit type if the function doesn't return anything on success. That's about as generic as one can get with a single "interface" type.
[1]: https://docs.spring.io/spring-framework/docs/current/javadoc...
QuaternionsBhop
I have never seen anything use Result<_,&'static str>, that is such an anti-rust thing to start with.
adastra22
LLMs love to do this. I assume they are trying to write JavaScript or Python or whatever, but in Rust.
I have never seen an actual Rist programmer do this, and that was clue #1 that TFA was AI generated without review.
bigstrat2003
I do when prototyping. Long term you don't really want to pass around &str errors, but they are quick and dirty and easy to get rolling with.
adastra22
Seems just as quick to make an enum with thiserror string conversion? Not much boilerplate at least.
hardwaresofton
OP should really mention that they made stackerror. I couldn’t shake the feeling that this read like an ad for stackerror… and of course the author is the crate writer. This feels somewhat disingenuous without a disclaimer that you wrote the lib and there are other ways.
The general advice is good (except for the awkward use of std error), so for anyone who wants to know what rustaceans are actually using:
- std error when it’s required
- anyhow for flexibly dealing with large classes of errors and rethrowing (often in bin crates or internally in a lib crate ), use anyhow::Context to tag errors
- thiserror for building and generating custom errors (in a lib crate)
- miette/eyre for more advanced features
Watch out for exposing error types in public API because then you are bound to push a breaking change if the upstream does.
Anyhow will probably never have a v2 at this point IMO, the entire Rust ecosystem might have to rev!
[EDIT] dont want to suggest that people avoid stackerror, just want to show what other ecosystem projects there are! stackerror seems to fit the hole of anyhow.
adastra22
How is this different from the even more ergonomic “#[from]” provided by thiserror?
echelon
Are all of these proc macros worth it? The compile times for proc macros explode.
I'd rather hand-roll errors than deal with more proc macros. Or better yet, have code gen pay the cost once and never deal with it again.
duped
Frankly, std::io:Error::other is good enough most of the time.
alfiedotwtf
Cognitive load is more expensive than compilation time.
echelon
Compilation time turns into cognitive load via frustration. Death by a thousand cuts.
faangguyindia
Rust used to be pretty hard to read and write, now with ai coding agent not anymore.
Analemma_
Have you had success doing non-trivial Rust with AI agents? In my experience they're all pretty bad at it once you get beyond the basics and start having tricky lifetimes and complicated types, but I'm interested to hear what people have done to make it better.
Spooky_Fusion1
Thankyou for pointing out a Rust, crate, error handler. Judging by the other comments, it's just as well you did,as I will look more closely at its use with virtual DOM. Thankyou.
This just feels like recreating exceptions, but with more complicated syntax.