anyhow for Applications, thiserror for Libraries

You are writing a CLI. Somewhere deep in the call stack serde_json::from_slice fails, and three frames up you know it was the manifest at ./services/pay.toml. Your options are: define an enum, wrap the serde error, implement Display, implement source, write the From impl — or add one word:

use anyhow::{Context, Result};

fn load_manifest(path: &Path) -> Result<Manifest> {
    let bytes = std::fs::read(path)
        .with_context(|| format!("reading manifest {}", path.display()))?;
    let manifest = toml::from_slice(&bytes)
        .context("parsing manifest as TOML")?;
    Ok(manifest)
}

anyhow::Error is the Box<dyn Error + Send + Sync + 'static> you met in the previous topic, plus three things a plain box does not give you: a message stack, backtrace capture, and typed downcasting — all without declaring a single variant. anyhow::Result<T> is just Result<T, anyhow::Error>, so signatures stay one line.

context and with_context attach a layer on the way out, and main can add the outermost one itself:

fn main() -> anyhow::Result<()> {
    let manifest = load_manifest(Path::new("./services/pay.toml"))
        .context("starting service")?;
    Ok(())
}

When the file is missing, {:?} at the top of main prints:

Error: starting service

Caused by:
    0: reading manifest ./services/pay.toml
    1: No such file or directory (os error 2)

Read that carefully: the last context attached is the outermost layer and prints as the headline, with every earlier context and the original OS error stacked beneath it. The discipline that follows is about ordering — write contexts from the innermost frame outward (reading manifest X deep in the loader, then starting service at the top) and the report reads as a story of what the program was doing when the root cause fired. The second rule is about cost: .context(msg) takes an owned String and builds it at the call site on every execution, whereas .with_context(|| format!("... {id}")) takes a closure invoked only on the Err path. Use with_context whenever the message interpolates anything non-trivial.

Failure without an error value is the other convenience: anyhow! creates an error from a format string, bail!("unsupported mode: {mode}") returns early with one, and ensure!(cond, "token expired") is if !cond { bail!(...) }.

fn authorize(tok: &str) -> Result<()> {
    ensure!(tok.len() >= 32, "token too short: {} bytes", tok.len());
    Ok(())
}

Backtraces are where anyhow earns the "applications" label. With RUST_BACKTRACE=1, {:?} on an anyhow::Error appends the capture, so a top-level fn main() -> anyhow::Result<()> prints where the failure originated, not just the chain of messages — invaluable when the real error is swallowed three modules below your context. Keep main thin: propagate with ? all the way up and let the Debug formatting at the top do the reporting; catch errors in main manually only when you need a specific exit code or a JSON error envelope for a service.

Two costs worth knowing before you commit. First, anyhow::Error erases the variant structure — a caller who must act (retry vs. 404 vs. fatal) needs err.downcast_ref::<LibError>(), which works only while the concrete type survived and is Send + Sync + 'static. Second, anyhow is a dependency of your public API if you expose it; that is fine for a binary, and precisely why libraries reach for the other crate instead.

Flip the perspective: your crate is billing-core, and three services depend on it. One of them retries on transient failures, one maps "invoice not found" to HTTP 404, and one logs everything as a fatal bug. They cannot do any of that with a message string — they need to match. That requirement decides the crate for you before you write a line: a library exposes a typed enum; thiserror is the derive that builds it.

use thiserror::Error;

#[derive(Debug, Error)]
pub enum BillingError {
    #[error("invoice {id} not found")]
    NotFound { id: String },

    #[error("payment provider rejected the charge: {0}")]
    ProviderRejected(String),

    #[error("transient upstream failure")]
    Transient(#[from] std::io::Error),   // source() + impl From<io::Error>

    #[error("retry budget exhausted after {attempts} attempts")]
    RetryExhausted { attempts: u32 },
}

thiserror expands to the exact code from the previous topic: Display from the #[error] format strings, Error::source() returning the field marked #[source] (or named source, or any field that is itself an error when #[from] is present), and impl From<...> for each #[from] — the trait that makes ? work inside your crate. It is a compile-time-only dependency: nothing runs, there is no runtime to link, and it costs nothing downstream.

For the interview question "what does the derive actually generate?", the manual equivalent of the Transient variant is this:

impl std::fmt::Display for BillingError {
    fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {
        match self {
            Self::Transient(_) => write!(f, "transient upstream failure"),
            // ...one arm per variant, from the #[error] strings
            _ => Ok(()),
        }
    }
}

impl std::error::Error for BillingError {
    fn source(&self) -> Option<&(dyn std::error::Error + 'static)> {
        match self { Self::Transient(e) => Some(e), _ => None }
    }
}

impl From<std::io::Error> for BillingError {
    fn from(e: std::io::Error) -> Self { BillingError::Transient(e) }  // what #[from] writes
}

Thirty lines of boilerplate per enum, gone — and regenerated consistently the day you add a variant.

Designing the variants is the actual work; the derive is mechanical. Three constraints come from the contract you are publishing:

1. Variant count is API surface. Every variant is a match arm your callers must eventually handle. Three to six coarse outcomes beat twenty internal states; expose internals behind one Internal(String)-style variant (or keep it private to the enum's module) rather than leaking serde_json::Error as a public case.
2. Add #[non_exhaustive] as soon as you intend to add variants — it forces callers to keep a catch-all arm, turning a future addition from a breaking change into a patch release.
3. Never expose anyhow::Error in a public signature. Downstream crates would inherit the dependency, ? conversion to their error types gets awkward, and they cannot match anything. anyhow belongs inside your binary or your private test code; thiserror types belong on the boundary.

Why not just return Box<dyn Error> from a library? Because a box removes exactly the two things these callers need — matching and downcasting-by-design — and it makes your crate's failure mode depend on allocation and type erasure rather than on a documented enum. Box is a boundary tool (previous topic); at a public boundary, types communicate.

The interview framing to memorize: thiserror is for the crate that defines errors; anyhow is for the crate that consumes them. A library states what can go wrong; an application decides how to report it. The next chapter shows the seam where the two meet in one binary.

Most real systems use both crates in the same dependency tree, divided by who consumes each error. The library layer (db-core, billing-core) publishes typed enums built with thiserror; the application layer (billingd, a CLI, an integration test suite) pulls those errors upward with anyhow and adds narrative context.

// billing-core — typed contract
#[derive(Debug, thiserror::Error)]
pub enum BillingError {
    #[error("invoice {0} not found")]
    NotFound(String),
    #[error("provider timeout")]
    Timeout,
}

// billingd/src/main.rs — application
use anyhow::{Context, Result};

fn charge_all(cfg: &Config) -> Result<()> {
    for inv in &cfg.invoices {
        charge(inv)
            .with_context(|| format!("charging invoice {inv}"))?;  // BillingError -> anyhow::Error
    }
    Ok(())
}

The ? in charge_all compiles because anyhow::Error has a blanket From<E: std::error::Error + Send + Sync + 'static> — the library error must satisfy those three bounds, which is why thiserror enums should derive nothing that blocks them (keep them Send + Sync: no Rc, no raw pointers). Context layers accumulate around the typed error, and the printed report is both:

Error: charging invoice inv_9f3

Caused by:
    0: provider timeout

The application still has escape hatches back to structure when it needs a policy decision:

if let Some(BillingError::Timeout) = err.downcast_ref::<BillingError>() {
    return schedule_retry(err);
}

downcast_ref recovers the original concrete type because anyhow stores it rather than stringifying — this is the single most important property that distinguishes it from format!("{}", e).into(). The rule that keeps this honest: downcast to the type the library actually returned, and only while it is still Send + Sync + 'static.

At the very edge of a service, the two styles meet one last time — the handler decides what an erased error means for the protocol:

async fn handler(State(s): State<Store>) -> impl IntoResponse {
    match s.fetch_invoice("inv_1").await {
        Ok(inv) => (StatusCode::OK, Json(inv)).into_response(),
        Err(err) if err.downcast_ref::<BillingError>()
            .map_or(false, |e| matches!(e, BillingError::NotFound(_))) =>
                (StatusCode::NOT_FOUND, "invoice not found").into_response(),
        Err(err) => {
            error!(?err, "invoice fetch failed");   // full context chain in the log
            (StatusCode::INTERNAL_SERVER_ERROR, "internal error").into_response()
        }
    }
}

This is the whole strategy in one function: structured branching where the protocol needs it, narrative logging where it does not, and a generic 500 so internal error text never leaks to a client. The same split applies to tests — #[test] fn t() -> anyhow::Result<()> gives you ? and readable failures for free, while the library's own unit tests assert on typed variants, because matching in a test is exactly what matching is for.

Pick by asking one question per crate — "who reads these errors?" Concretely:

One last cost note for interviews: context layers allocate a String per attached message (only on failure), and each ? conversion moves a boxed error — both trivial next to I/O, but the reason a hot inner loop returns a typed enum instead of anyhow::Error. With the error strategy set, the roadmap shifts to data: Vec and Dynamic Arrays is where the values these errors describe actually live.