What thiserror and anyhow actually generate

Nothing in this article can be compiled here. thiserror and anyhow are external crates, and thiserror is a procedural macro, which this course’s single-file no-crates harness cannot build. Everything below is read-only illustration.

That is fine, because the point is not to use them — it is to read them. Having written Display, Error, source(), From and a context extension trait by hand over the last few items, you can now look at these macros and see exactly which of those they are writing for you. Which is a much better position than the usual one, where a beginner copies #[error("...")] off Stack Overflow and never finds out what it did.

thiserror, translated

Here is a thiserror enum you will meet in real code:

use thiserror::Error;

#[derive(Debug, Error)]
pub enum ConfigError {
    #[error("key `{0}` is missing")]
    MissingKey(String),

    #[error("could not read the config file")]
    Io(#[from] std::io::Error),

    #[error("key `{key}` is not an integer")]
    BadInt {
        key: String,
        #[source]
        source: std::num::ParseIntError,
    },

    #[error(transparent)]
    Other(#[from] anyhow::Error),
}

And here is what each attribute generates, in the vocabulary you already have.

Expand the first two variants by hand and you get code you have already written:

impl std::fmt::Display for ConfigError {
    fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {
        match self {
            ConfigError::MissingKey(k) => write!(f, "key `{k}` is missing"),
            ConfigError::Io(_) => f.write_str("could not read the config file"),
            // ...
        }
    }
}

impl std::error::Error for ConfigError {
    fn source(&self) -> Option<&(dyn std::error::Error + 'static)> {
        match self {
            ConfigError::MissingKey(_) => None,
            ConfigError::Io(e) => Some(e),
            ConfigError::BadInt { source, .. } => Some(source),
            // ...
        }
    }
}

impl From<std::io::Error> for ConfigError {
    fn from(e: std::io::Error) -> Self { ConfigError::Io(e) }
}

There is no third thing. thiserror is a typing-saving device with zero runtime component — it does not exist at run time, it adds no dependency to your callers’ binaries, and its output is code you could have written. That is also why it is safe to use in libraries: nothing about it leaks into your public API except the impls, which you wanted anyway.

anyhow, translated

use anyhow::{Context, Result, bail, anyhow};

fn load(path: &str) -> Result<Config> {
    let text = std::fs::read_to_string(path)
        .with_context(|| format!("reading config from {path}"))?;

    if text.is_empty() {
        bail!("config file {path} is empty");
    }

    let port: u16 = text.trim().parse().context("parsing port")?;
    Ok(Config { port })
}

Piece by piece:

• anyhow::Error is morally Box<dyn Error + Send + Sync + 'static>, plus a backtrace and a stack of context messages. (The real implementation is a single-word thin pointer to a heap block holding a vtable and the payload — narrower than a boxed trait object, which is two words. That is an optimisation, not a different idea.)
• anyhow::Result<T> is a type alias for std::result::Result<T, anyhow::Error>. Nothing more.
• .context(msg) / .with_context(|| msg) is the extension trait you built in item 6.19: a trait with one method, blanket-implemented for Result<T, E>, that wraps the error with a message and keeps the original as the source. with_context is the lazy form, for when building the message allocates — the same eager/lazy distinction as unwrap_or vs unwrap_or_else.
• anyhow!("…") constructs an error from a format string; bail!("…") is return Err(anyhow!("…")).
• {:#} formats the whole chain on one line — the render function you wrote by hand, joining with ": ". {:?} gives the multi-line form with the backtrace.

So the value anyhow adds over Box<dyn Error + Send + Sync> is: the context stack, the backtrace, the thin pointer, and downcast that still works through all of it. Those are real conveniences. None of them is a mechanism you have not now seen.

The neighbours

You will run into these too, and being unsurprised is most of the benefit:

• snafu — like thiserror, but context-first: it generates context selectors so that adding context is checked by the type system rather than by a string.
• eyre and color-eyre — an anyhow fork with pluggable report handlers. color-eyre gives you coloured, sectioned terminal output with suggestions. Same shape, better presentation.
• miette — diagnostics with source spans, labels and help text, in the style of rustc’s own errors. Worth it for anything that parses a language.
• thiserror 2.x — a 2024 rewrite; the attributes above are unchanged.

#[derive(Debug, Error)]
pub enum ConfigError {
    #[error("could not read {path}")]
    Read { path: String, #[source] source: std::io::Error },

    #[error("could not write {path}")]
    Write { path: String, #[source] source: std::io::Error },
}

What to take away

The two crates are not abstractions over error handling — they are code generators for the exact pattern you spent this track writing by hand:

• thiserror writes your Display, Error, source() and From impls.
• anyhow gives you a boxed error with a context stack and a backtrace, plus the extension trait that pushes onto it.

Neither introduces a mechanism. If you ever hit an error message from one of them that makes no sense, expand the macro in your head into the impls above and the message will be about those impls, not about magic.