May 30, 2026
Error wars: crate or chaos?
Custom Errors Are Non-Negotiable in My Rust Applications
Rust dev says custom errors are a must, but the comments instantly yelled 'just use the crate'
TLDR: The article says Rust apps should convert every kind of failure into one custom error type so the whole codebase stays sane. But the comments stole the show by arguing this is much easier with a popular helper tool, turning a coding tip into a mini showdown over purity versus convenience.
A Rust developer rolled in with a firm manifesto: if your app talks to lots of different services, you need one homemade error system to keep everything tidy, readable, and under control. In plain English, the article argues that when a program fails in different ways, you should translate all those failures into one house style instead of letting chaos leak everywhere. The vibe from the post is pure "I have seen the mess, and I refuse to live like this anymore."
But the real fireworks came from the community. The loudest reaction was basically: "Why are we acting like this has to be done the hard way?" Commenter treyd jumped in with the classic internet mood of calm correction mixed with a little flex, pointing to the thiserror crate as the obvious shortcut. That one comment carries the whole thread’s tension: one side loves the article’s clean, disciplined "do it yourself" philosophy, while the other side is waving a popular helper tool and asking why anyone would skip the easy button.
And yes, there’s a little comedy in the clash. The article frames outside tools as "janky," while the comments answer with the digital equivalent of "sir, respectfully, that’s what the good tools are for." It’s the kind of programming drama the internet lives for: one person declaring a non-negotiable life rule, and the replies immediately negotiating it.
Key Points
- •The article describes heterogeneous error types from Rust subsystems like databases, APIs, and configuration as a common source of boilerplate.
- •It uses a `run_pipeline_ugly` example to show how returning `Box<dyn std::error::Error>` can require manual boxing and reduce type specificity.
- •The proposed solution is to define a single custom `AppError` enum that acts as the unified error contract for the application.
- •The article recommends having modules return `Result<T, AppError>` rather than exposing many external library error types.
- •It explains `map_err` as an interception layer for converting foreign errors into `AppError` while optionally logging or adding higher-level context.