Stop Forwarding Errors, Start Designing Them It’s 3am. Production is down. You’re staring at a log line that says: Error: serialization error: expected ',' or '}' at line 3, column 7 You know JSON is broke. But you have zero idea why, where, or who caused it. Was it the config loader? The user API? The webhook consumer? The error has successfully bubbled up through 20 layers of your stack, preserving its original message perfectly, yet losing every scrap of meaning along the way. We have a name for this. We call it “Error Handling.” But in reality, it’s just Error Forwarding. We treat errors like hot potatoes—catch them, wrap them (maybe), and throw them up the stack as fast as possible. You add a println!, restart the service, wait for the bug to reproduce. It’s going to be a long night. As noted in a detailed analysis of error handling in a large Rust project: “There’re tons of opinionated articles or libraries promoting their best practices, leading to an epic debate that never ends. We were all starting to notice that there was something wrong with the error handling practices, but pinpointing the exact problems is challenging.” What’s Wrong with Current Practices The std::error::Error Trait: A Noble but Flawed Abstraction Rust’s std::error::Error trait assumes errors form a chain—each error has an optional source() pointing to the underlying cause. This works for most cases; the vast majority of errors have no source or a single one. But as a standard library abstraction, it’s too opinionated. It categorically excludes cases where sources form a tree: a validation error with multiple field failures, a timeout with partial results. These scenarios exist, and the standard trait offers no way to represent them. Backtraces: Expensive Medicine for the Wrong Disease Rust’s std::backtrace::Backtrace was meant to improve error observability. They’re better than nothing. But they have serious limitations: In async code, they’re nearly useless. Your backtrace will contai...
First seen: 2026-01-04 20:21
Last seen: 2026-01-05 04:22