The question mark Operator

Take a function that reads a file, parses it, and converts it to a struct — three steps, three chances to fail. Written by hand:

fn load(path: &Path) -> Result<Config, io::Error> {
    let text = match fs::read_to_string(path) {
        Ok(t) => t,
        Err(e) => return Err(e),
    };
    let cfg = match parse(&text) {
        Ok(c) => c,
        Err(e) => return Err(e),
    };
    Ok(cfg)
}

The ? operator collapses it to two lines:

fn load(path: &Path) -> Result<Config, io::Error> {
    let text = fs::read_to_string(path)?;
    let cfg = parse(&text)?;
    Ok(cfg)
}

Its meaning is exactly this, and interviewers routinely ask you to say it out loud:

let text = match fs::read_to_string(path) {
    Ok(v)  => v,
    Err(e) => return Err(e.into()),   // early return from the FUNCTION
};

Two clauses matter. On Ok, ? unwraps the value and execution continues. On Err, it returns from the enclosing function — not from the current block, not from the loop, not from the async task's current await point. This is the most common misreading of the operator:

fn drain(conn: &mut Connection) -> Result<(), io::Error> {
    loop {
        let msg = conn.recv()?;   // returns from drain(), NOT just from the loop
        if msg.is_heartbeat() { continue; }
        process(msg);
    }
}

Beginners expect ? to try the next loop iteration; it does not. To keep going after a failure you need an explicit match or an if let Err(e) = ....

The second clause — e.into() — is the conversion the compiler inserts. ? does not pass the error through untouched; it applies From::from to it, so an error of type A becomes the function's declared error type B when impl From<A> for B exists. Since Rust has a blanket impl<T> From<T> for T, a same-type error passes through unchanged and you never notice the machinery. The moment the types differ, ? is doing real work: converting an io::Error into your own enum variant is a one-character difference between "compiles" and "mismatched types."

fn main() -> Result<(), Box<dyn std::error::Error>> {
    let cfg = load(Path::new("app.toml"))?;   // io::Error -> Box<dyn Error> automatically
    println!("{cfg:?}");
    Ok(())
}

That main form is worth memorizing: when main returns Result<(), E: Debug> (or Box<dyn Error>), a returned Err is printed with Debug and the process exits with code 1 instead of 0 — a clean way to keep error handling at the top level without a single unwrap.

Finally, the constraint: only a function whose return type implements Try may contain ?. In practice that means Result<T, E>, Option<T>, Box<dyn Error>-returning Results, or the nightly Try trait. Put ? inside a function returning () and you get error[E0308]: the ? operator can only be used on Result and Option (or a type that implements std::ops::Try) plus a note that the function must return Result or Option. The fix is always the same: change the signature, or handle the error in place. Closures are the trap — |x| do_something(x)? will not infer a return type, so annotate it: |x| -> Result<T, MyError> { Ok(do_something(x)?) }.

Option gets the same treatment with a shorter desugaring: opt? is match opt { Some(v) => v, None => return None } — no conversion step, because there is no error payload to convert. An Option-returning function therefore reads like a chain of partial computations, which is the mental bridge to the Result version you already know.

Now the half of ? that people learn the hard way. Given:

fn read_key(path: &Path) -> Result<Secret, io::Error> { ... }

fn load_secrets() -> Result<Vault, ConfigError> {
    let key = read_key(path)?;   // io::Error in, ConfigError out
    ...
}

read_key hands back an io::Error; load_secrets promises a ConfigError. The compiler makes it work by expanding ? to return Err(ConfigError::from(err)). So the real contract is:

? requires impl From<IncomingError> for OutgoingError. No such From impl, no compile.

#[derive(Debug)]
enum ConfigError {
    Io(std::io::Error),
    Parse(toml::de::Error),
}

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

Two lines per source error, and now every ? from fs and from the TOML parser works in the same function. thiserror later generates these From impls for you — see Implementing the Error Trait.

The conversion matrix is what interviewers actually probe:

Bridging is your job: Result → Option with .ok(), Option → Result with .ok_or(err) or .ok_or_else(err_fn) (the lazy form when constructing the error costs work) — the same bridges introduced in Option Combinators. Once bridged, ? flows normally.

A pattern that combines both halves — conversion and collection — is worth having in muscle memory, because parsing a list is where ? earns its keep:

let ports: Vec<u16> = raw_lines
    .iter()
    .map(|l| l.trim().parse::<u16>())
    .collect::<Result<Vec<u16>, _>>()?;   // first bad line returns the whole function

Here ? does not touch the individual ParseIntErrors; collect has already fused the iterator of Results into a single Result<Vec<_>, _>, and ? propagates that one, converting it to the function's error type if needed. Notice what it does not do: it fails on the first bad line with no indication of which line. When the caller needs the index, you map it into your own error before collecting — .map(|(i, l)| l.parse().map_err(|e| ConfigError::BadLine { i, e })) — which is map_err from the next chapter doing its job one frame earlier.

One design consequence deserves attention: conversion erases where the error came from unless you keep the chain. If ConfigError::from(io_err) stores the io::Error inside a variant, source() can still walk back to it — that is the whole point of std::error::Error::source. If you instead stringify it (format!("{e}").into()), the original type is gone and no caller can downcast or inspect the OS error code. Convert into your typed enum; do not flatten it into a String on the way.

Box<dyn Error> is the escape hatch with different trade-offs: impl<E: Error + 'static> From<E> for Box<dyn Error> exists in the standard library, so ? boxes almost any error automatically with zero From work from you. You gain convenience and lose static typing — callers must downcast to distinguish "file missing" from "permission denied." In a binary that is usually fine; in a library, anyhow for Applications, thiserror for Libraries settles the choice.

The interview-ready phrasing: "? is an early return plus From::from on the error — it never changes control flow beyond returning from the enclosing function, and it never converts between Result and Option."

? handles the shape of failure propagation. It deliberately does not handle the content — and three everyday situations require you to drop back to an explicit match, or to decorate before the operator runs.

1. You must log, metric-tag, or add context before returning. ? returns immediately, so no statement you write after it will run:

let rows = db.query(sql).map_err(|e| {
    warn!(error = %e, sql, "query failed");
    e                       // hand the error back unchanged
})?;

map_err wraps the failure, lets you observe it, and still returns it for ? to consume. The std-only alternative since Rust 1.76 is inspect_err, which runs a closure on the error and returns the original untouched — db.query(sql).inspect_err(|e| error!(%e))?; — cleaner when you only need to look. When you need control flow inside the error branch (retry, fall back to a cache, then maybe return), only an explicit match fits:

match db.query(sql) {
    Ok(rows) => rows,
    Err(e) if is_transient(&e) => cache.serve(key),
    Err(e) => return Err(AppError::from(e)),
}

2. You must recover partially, not propagate. ? is all-or-nothing. Parsing a batch where individual items may be bad needs per-item handling:

let parsed: Vec<Item> = raw.iter()
    .filter_map(|line| match line.parse() {
        Ok(item) => Some(item),
        Err(e) => { skipped += 1; debug!("skipping {line:?}: {e}"); None }
    })
    .collect();

3. The error type must be adapted, not just converted. Converting io::Error into AppError::NotFound by inspecting the OS code is a decision From cannot make (it receives no context about which file), so you do it explicitly:

fn open(path: &Path) -> Result<File, AppError> {
    fs::open(path).map_err(|e| match e.kind() {
        io::ErrorKind::NotFound => AppError::NotFound(path.display().to_string()),
        io::ErrorKind::PermissionDenied => AppError::Forbidden(path.display().to_string()),
        _ => AppError::Io(e),
    })
}

Note the ownership detail that trips people up: ? moves the error into the return value. If the function still needs to read from it — format it twice, push it into a log and return it — take a reference first (e.to_string(), &e) or clone. Errors are rarely Copy, and this is where "use of moved value: e" errors come from.

Async code adds no new rules: await first, then ? — let body = client.get(url).send().await?; — because ? operates on the awaited Result, not on the future. Inside map/and_then closures you hit the missing-return-type problem from the first chapter; annotate the closure return type and keep using ? normally.

Finally, the discipline that keeps ? honest: propagate typed errors with ?, record context with map_err/inspect_err, and reserve raw match for branches that genuinely do something else. When every function in the stack uses that split, the error report a user sees still has the file name, the SQL, and the OS code attached — which is exactly what building Display and source() on your own enum is for, and the next topic in this roadmap.

The three compiler errors you will meet with ?, and the one-line fix for each: