Scoped Error in Rust

Summary

Scoped Error in Rust 西元2026年05月22日 - Kan-Ru Chen I’ve never been fully satisfied with any error handling crate in Rust. I’ve tried many and even developed a few helpers. Here are the key issues I found with each. Theses are issues my scoped-error crate tries to address. The Inspiration anyhow - good for a drop-in Error type that just works, but requires adding .with_context() everywhere. It’s verbose and repetitive. Error reporting requires knowing how anyhow::Error handles format strings. Error propagation lacks location information; the alternative is backtrace, which pulls in heavy std dependencies. thiserror - good for defining custom Error types. The #[from] implementation encourages a single Error type that encompasses all possible sources. But the ergonomics stop there. Using these types is still tedious if you want per-module errors with good context. The improvement over manually rolling Error types seems small compared to the syn and compile-time overhead. snafu - combines manual context attachment with anyhow and thiserror patterns in one crate. However, I feel like I’m encoding all my error branches into Snafu contexts. Those implementation details don’t need to be public, yet snafu tightly couples the Error type to them. Maybe I’m using it wrong. exn - a refreshing approach to error handling. I actually started my crate based on the pattern from the blog post Stop Forwarding Errors, Start Designing Them. The minor issues with exn 0.3 are: (1) you still need to remember .or_raise(err) for each fallible operation, and it’s easy to miss for intra-module method calls; (2) the Exn wrapper itself is not a std Error, so interop with other error types requires adapters like exn-anyhow or exn-stderr. While switching between these error crates, I kept noticing a gap: with anyhow-like crates, you attach context at each call site, but the method itself lacks it. Example: use anyhow::Result; fn read_config() -> Result<String> { let raw = std::fs::read_to_string("con...