Ergonomic Errors in Rust: Write Fast, Debug with Ease, Handle Precisely

Posted4 months agoActive4 months ago

garrinm

32 points

27 comments

gmcgoldr.github.ioTechstory

skepticalmixed

Debate

70/100

Rust ProgrammingError HandlingSoftware Development

Key topics

Rust Programming

Error Handling

Software Development

The article discusses ergonomic error handling in Rust, but the discussion is marred by skepticism about the proposed solution and concerns about the author's potential bias.

Snapshot generated from the HN discussion

Discussion Activity

Active discussion

First comment

Peak period

30-33h

Avg / period

5.4

Comment distribution27 data points

Loading chart...

Based on 27 loaded comments

Key moments

01Story posted
Aug 22, 2025 at 12:57 PM EDT
4 months ago
Step 01
02First comment
Aug 23, 2025 at 5:58 PM EDT
1d after posting
Step 02
03Peak activity
12 comments in 30-33h
Hottest window of the conversation
Step 03
04Latest activity
Aug 24, 2025 at 5:53 AM EDT
4 months ago
Step 04

Generating AI Summary...

Analyzing up to 500 comments to identify key contributors and discussion patterns

Discussion (27 comments)

Showing 27 comments

TheCleric

4 months ago

3 replies

This just feels like recreating exceptions, but with more complicated syntax.

XorNot

4 months ago

2 replies

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.

MindSpunk

4 months ago

1 reply

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

4 months ago

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

b_e_n_t_o_n

4 months ago

Go unironically gets this right - you just treat them like a normal value instead of trying to make them more "ergonomic".

catlifeonmars

4 months ago

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.

IshKebab

4 months ago

Yeah but only if you were to always use checked exceptions, and have mandatory try/catch around every function call, and have a much nicer syntax for throwing exceptions with added context. I've never seen any language that did that but I guess it would be possible.

adastra22

4 months ago

1 reply

How is this different from the even more ergonomic “#[from]” provided by thiserror?

echelon

4 months ago

2 replies

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.

alfiedotwtf

4 months ago

1 reply

Cognitive load is more expensive than compilation time.

echelon

4 months ago

2 replies

Compilation time turns into cognitive load via frustration. Death by a thousand cuts.

dijksterhuis

4 months ago

1 reply

https://xkcd.com/303/

(compilation time is good for brain switch off time - i.e. reducing cognitive load).

echelon

4 months ago

I find it's great for letting ADHD take over steering the ship and losing total focus on what needs to be done.

Which is more or less what this XKCD encapsulates.

adastra22

4 months ago

How long are your compiles? The longest I’ve ever seen is a massive Bevy project with 700 dependencies, and it still compiled in <5min from an empty cache, and then 2-3 second incremental builds (mostly link time).

duped

4 months ago

Frankly, std::io:Error::other is good enough most of the time.

QuaternionsBhop

4 months ago

1 reply

I have never seen anything use Result<_,&'static str>, that is such an anti-rust thing to start with.

adastra22

4 months ago

2 replies

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

4 months ago

2 replies

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

4 months ago

Seems just as quick to make an enum with thiserror string conversion? Not much boilerplate at least.

lawn

4 months ago

You can also use eyre! with it's accompanying Result for even easier and faster development.

db48x

4 months ago

I’m an actual Rust programmer, and I’ve done that. Especially for the first iteration of something when I’m not yet sure what will be included, or when the errors are just going to be printed to the terminal as the program exits.

faangguyindia

4 months ago

1 reply

Rust used to be pretty hard to read and write, now with ai coding agent not anymore.

Analemma_

4 months ago

1 reply

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.

faangguyindia

4 months ago

yes i did, try aistudio > gemini pro 2.5 from web console on your programm lemme know how well it works.

hardwaresofton

4 months ago

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.

imtringued

4 months ago

>And errors are consumed by two distinct consumers with different needs: the developer debugging an application, and the caller making error handling decisions at runtime.

Three. Three distinct consumers. Get that in your head. When your application errors out on startup, it's the user who sees the error message. File system errors without seeing the path of the file are useless.

_aobj

4 months ago

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.

View full discussion on Hacker News

ID: 44986875Type: storyLast synced: 11/20/2025, 4:35:27 PM

Want the full context?

Jump to the original sources

Read the primary article or dive into the live Hacker News thread when you're ready.

Open link View on HN