Error-Handling on

Lesson 10: Production Error Architecture — Logging, reporting, recovery

Sun, 28 Jul 2024 11:30:00 +0000

I shipped a Rust service to production once with great error types, proper Result propagation, context chains — the whole nine yards. And then I couldn’t debug anything because every error got logged as a single flat string with no request ID, no trace correlation, and no distinction between “user sent bad input” and “our database is on fire.” Having good error types is half the battle. The other half is what you do with those errors when they reach the top of your stack.

Lesson 9: panic!, unwrap, expect — When crashing is correct

Wed, 24 Jul 2024 07:55:00 +0000

There’s a pervasive myth in the Rust community that unwrap() is always bad. I’ve seen code reviews where people mechanically replace every unwrap() with a match or .expect(), even when the unwrap() was perfectly correct. The truth is more nuanced: panic! is a tool, and like any tool, the question isn’t “should I ever use it?” but “when is it the right choice?”

What panic! Actually Does

When you call panic!(), Rust does one of two things depending on your configuration:

Lesson 8: Adding Context — Error chains and backtraces

Sun, 21 Jul 2024 13:10:00 +0000

Picture this: it’s 2 AM, your pager goes off, and the log says "connection refused". Connection to what? From where? During which operation? That single error message is technically correct and practically useless. I’ve been in that exact situation enough times to develop strong opinions about error context. Every error in a production system should answer three questions: what happened, where did it happen, and what was the system trying to do when it happened.

Lesson 7: Library vs Application Error Strategy — They're not the same

Thu, 18 Jul 2024 09:40:00 +0000

I learned this the hard way. I was building a parsing library and used anyhow::Error as my error type in all public functions. A user opened an issue: “I can’t match on your errors to handle different parse failures differently.” They were right. I’d designed a library with application-level error handling, and it was a terrible experience for consumers. Took me a weekend to refactor everything to typed errors.

Libraries and applications have fundamentally different error handling requirements. Mix them up and you’ll either frustrate your users or drown in unnecessary boilerplate.

Lesson 6: anyhow — When you don't care about the type

Tue, 16 Jul 2024 16:20:00 +0000

There’s a dirty secret in Rust error handling: half the time, you don’t actually need typed errors. You need errors that are easy to create, easy to chain, and easy to print. That’s anyhow. Same author as thiserror (David Tolnay), completely different use case. Where thiserror is for defining precise error types, anyhow is for using errors without ceremony.

The Problem anyhow Solves

Without anyhow, when you have a function that can fail in multiple unrelated ways, you either:

Lesson 5: thiserror — Derive your way to clean errors

Sun, 14 Jul 2024 10:00:00 +0000

After writing my third custom error type by hand — with the Display impl, the Error impl, the From impls — I thought, “there has to be a better way.” There was. It’s called thiserror, and it’s probably the most widely-used error handling crate in the Rust ecosystem. David Tolnay wrote it, which means it’s well-designed, well-maintained, and does exactly one thing with zero bloat.

What thiserror Does

thiserror is a derive macro that generates Display, Error, and From implementations for your error types. It produces the exact same code you’d write by hand — no runtime cost, no extra dependencies at runtime (it’s a proc-macro, so it’s only a compile-time dependency).

Lesson 4: Designing Custom Error Types — Your domain, your errors

Thu, 11 Jul 2024 19:15:00 +0000

I once worked on a project where every error was Box<dyn std::error::Error>. Debugging was miserable. When something failed in production, the logs said things like “invalid input” with zero context about which input, where in the pipeline, or why it was invalid. That’s when I learned that good error types aren’t an afterthought — they’re part of your domain model.

Why Custom Error Types Matter

Standard library errors like io::Error and ParseIntError are fine for what they describe. But your application has its own failure modes. A payment processor doesn’t just fail with “IO error” — it fails with “card declined,” “insufficient funds,” “gateway timeout,” “idempotency key conflict.” These are domain-specific failures that deserve domain-specific types.

Lesson 3: The ? Operator — Propagation made elegant

Tue, 09 Jul 2024 14:30:00 +0000

Before the ? operator existed, Rust had try!() — a macro that did the same thing but looked ugly and nested poorly. When ? landed in Rust 1.13, it was one of those rare language changes where everyone immediately agreed it was better. I remember refactoring an entire crate the same week, deleting dozens of match blocks and try!() calls, and the code just… breathed.

What ? Actually Does

The ? operator is syntactic sugar for early return on error. When you write this:

Lesson 2: Result and Option — The foundation

Sun, 07 Jul 2024 08:45:00 +0000

When I first started writing Rust, I used match on every single Result and Option. My code looked like a staircase — match inside match inside match, indented halfway across the screen. Then a colleague showed me combinators, and suddenly the code read like prose instead of a tax form.

Result: More Than Just Ok and Err

You already know Result<T, E> has two variants. But Result comes with a huge set of methods that let you transform, combine, and short-circuit without writing explicit match blocks everywhere.

Lesson 1: Rust's Error Philosophy — No exceptions, no surprises

Fri, 05 Jul 2024 11:23:00 +0000

I spent three years writing Java before I touched Rust. In Java, any function call might throw an exception — checked, unchecked, runtime, whatever. You never really know what’s going to blow up until it does. The first time I wrote Rust code that forced me to handle every possible failure at the call site, I thought it was annoying. Six months later, I realized it was the sanest approach to errors I’d ever used.