Rust Errors: Result vs anyhow vs thiserror

TL;DR: Library code uses thiserror. Application code uses anyhow. Standard library uses Result. Each fills a real role.

The short version

Library code uses thiserror. Application code uses anyhow. Standard library uses Result. Each fills a real role.

This guide covers the mental model, the patterns that pay off, and the trade-offs that decide whether a technique fits your code.

Working example

Here's a minimal example you can run as-is. Drop it in a fresh file, run it, and trace through it once before reading the rest.

use std::collections::HashMap;

fn word_count(text: &str) -> HashMap<&str, u32> {
    let mut counts = HashMap::new();
    for word in text.split_whitespace() {
        *counts.entry(word).or_insert(0) += 1;
    }
    counts
}

fn main() {
    let text = "the quick brown fox the lazy dog";
    let counts = word_count(text);
    println!("{:?}", counts);
}

Why this pattern

The shape above shows up in real Rust codebases because it satisfies three constraints at once: it stays type-safe, it composes with the rest of the language's idioms, and it leaves a clear trail for the next developer (which, in six months, is you).

When you write the same pattern three times in a project, extract it. When you write it three times across projects, extract it into a shared library.

A common variant

The same idea adapted for a different shape. Notice how the structure stays the same — only the specifics change.

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

fn read_config(path: &str) -> io::Result<String> {
    let raw = fs::read_to_string(path)?;
    Ok(raw.trim().to_string())
}

fn main() {
    match read_config("config.toml") {
        Ok(s) => println!("{}", s),
        Err(e) => eprintln!("error: {}", e),
    }
}

Trade-offs to watch

Every pattern has a failure mode. The most common one here is over-application: developers who learn a technique apply it everywhere, including places where simpler code would have been clearer.

Rule of thumb: if the abstraction takes more lines to describe than it saves, the abstraction is wrong.

A more involved example

Once the basic pattern is clear, here's how it composes with surrounding code. Read this one slowly.

trait Greet {
    fn hello(&self) -> String;
}

struct User { name: String }

impl Greet for User {
    fn hello(&self) -> String {
        format!("hi, {}", self.name)
    }
}

fn main() {
    let u = User { name: "ada".into() };
    println!("{}", u.hello());
}

When to skip it

If the surrounding code is already simple, don't reach for Rust-specific cleverness. Boring code is a feature. Save the patterns for places where they actually pay off — usually at module boundaries, in shared libraries, or where the alternative would be 50 lines of repetition.

FAQ

Related reading

• The Rust Borrow Checker Mental Model
• Rust Lifetimes, Finally Explained
• Rust Iterators and Closures: The Power Combo
• Python Decorators Explained With Real Code
• React State Management in 2026