January 4, 2026
Hot potato errors, hotter comments
Stop Forwarding Errors, Start Designing Them
From hot-potato errors to real info — devs feud while users beg for clarity
TLDR: The piece argues apps should design useful, actionable errors instead of just passing them up. Comments erupt: some cheer Go’s blunt error checks, others slam real-world Rust for dumping cryptic messages on users, with calls for better UX and a unified approach everyone can actually adopt.
The article drags a familiar tech villain: “Error Forwarding,” where apps chuck problems up the chain like hot potatoes and hope a backtrace (a techy breadcrumb trail) saves the day. It calls for errors you can actually act on, shading Rust’s one-size-fits-all approach and pricey backtraces that don’t help with background tasks. The community? Absolute fireworks. Go-language fans strut in with “we told you so,” while Rust diehards debate whether neat tutorials match messy reality. One top comment says Go’s blunt “check every error” rhythm forces real thought, while another admits most apps just dump cryptic messages on users — no automatic fixes, no context, just vibes. Hardcore engineers pitch wild ideas like unique error codes you can search across a codebase, and even reserving a CPU register for errors (yes, really). Meanwhile, a user drops a relatable horror story: a 63GB photo transfer halted by a pop-up demanding “Retry, Ignore, Ignore all, Cancel,” proving bad error design isn’t just a developer headache — it’s your Sunday ruined. Pragmatists warn shiny new solutions need compatibility with existing tools like thiserror and anyhow or they’ll stall at the first library. The meme of the day? “It’s 3am, JSON broke” — with a sequel called “49 Frames of Poll,” referencing Rust backtrace woes.
Key Points
- •The article argues that Rust projects often forward errors up the stack without adding meaningful, actionable context.
- •Rust’s std::error::Error trait models errors as chains and cannot represent tree-shaped sources like multi-field validation failures.
- •std::backtrace::Backtrace is limited for async Rust, shows only origin rather than logical path, and is expensive to capture.
- •The Provider/Request API (RFC 3192) and generic member access (RFC 2895) introduce unpredictability and complexity in error context retrieval, with optimization challenges noted for LLVM.
- •The thiserror crate commonly encourages categorizing errors by origin; the article advocates designing structured errors focused on what callers can do.