Rust Error Handling: 5 Result Patterns That Save You

Rust has no exceptions and no null. You'll handle every failure as a value the compiler forces you to confront. It feels verbose for exactly one afternoon.

Then the payoff lands: Result makes failure paths visible, ? collapses boilerplate into one character, and typed errors turn midnight mysteries into match arms. Code reviews get calmer fast.

You'll build a config loader that degrades gracefully, chain three fallible calls with ?, and see how one team cut incident triage from hours to minutes. Errors become data.

Result<T, E> is an enum with two variants: Ok(T) for success and Err(E) for failure. The compiler forces you to handle both before using the inner value. There is no null to forget and no exception that jumps frames invisibly.

Option<T> is the sibling for absence: Some(T) or None. Use it for lookups and optional fields. Use Result when failure carries information worth acting on, like which file was missing.

The ? operator is early return for errors. Inside a function returning Result, writing fs::read_to_string(p)? unwraps success or returns the error after From conversion. Three fallible calls become three lines instead of three nested matches.

Conversions happen through the From trait. If your error enum implements From<io::Error>, IO errors flow into it automatically. Define those conversions once with thiserror and never hand-write them again.

use std::fs;
use std::io;

fn read_config(path: &str) -> Result<String, io::Error> {
    fs::read_to_string(path)
}

fn main() -> Result<(), io::Error> {
    let cfg = read_config("config.toml").unwrap_or_else(|_| String::from("default"));
    println!("config bytes: {}", cfg.len());
    Ok(())
}

Combinators transform results without nesting. .map() changes the success value, .map_err() changes the error, .unwrap_or() supplies a default, and .and_then() chains fallible steps. Each keeps the happy path flat and readable.

Reach for combinators in short pipelines and ? in longer ones. A two-step parse reads well as s.parse().map_err(...). A five-step checkout flow reads better as five ? lines with one error type.

fn parse_port(raw: &str) -> Result<u16, String> {
    raw.trim()
        .parse::<u16>()
        .map_err(|e| format!("bad port '{}': {}", raw, e))
}

fn main() {
    let port = parse_port("8080").unwrap_or(3000);
    println!("port: {}", port);
}

unwrap and expect panic when they meet Err. In tests that is fine: a failure should stop the test loudly. In request handlers it is a scheduled outage: one bad row kills the worker and everything it was doing.

Replace production unwraps with ? propagation or explicit fallbacks. Where an invariant truly cannot fail, use expect with a message naming it. Crash logs then explain themselves.

Libraries should expose typed errors callers can match. Derive them with thiserror: one enum, one variant per failure, #[from] for automatic conversion. Callers match variants and handle each case deliberately.

Binaries should use anyhow for context-rich reports. Attach .context() breadcrumbs at each layer, then print the chain with {:?}. Operators see the full story from top symptom to root file.

use std::num::ParseIntError;

#[derive(Debug)]
enum AppError {
    BadPort(ParseIntError),
    Empty,
}

impl From<ParseIntError> for AppError {
    fn from(e: ParseIntError) -> Self {
        AppError::BadPort(e)
    }
}

fn parse_port(raw: &str) -> Result<u16, AppError> {
    if raw.trim().is_empty() {
        return Err(AppError::Empty);
    }
    Ok(raw.trim().parse()?)
}

fn main() {
    match parse_port("8080") {
        Ok(p) => println!("port: {}", p),
        Err(e) => println!("error: {:?}", e),
    }
}

Panics are for bugs, not bad input. Indexing past a slice, dividing integers by zero, or hitting an impossible branch means the program logic is wrong. Panicking loudly is correct there.

Everything external can fail and must return Result: files, networks, parsing, user input. Ask one question per failure site: can the caller do something smarter than crash? If yes, return it.