Result, Option and the ? operator: error handling in Rust

What it is

Result<T, E> is an enum with Ok(T) and Err(E); Option<T> has Some(T) and None. There is no null pointer and no implicit unwrapping: to use the inner value the code must match, use if let, or call a method such as unwrap_or, map, and_then or ok_or. unwrap() and expect("...") extract the value and panic otherwise. The Rust book describes the question mark operator: expr? on a Result returns Err from the enclosing function early, after passing the error through the From trait to the function's declared error type; on an Option it returns None. It may only be used in a function whose return type is compatible, and main may return Result<(), Box<dyn Error>> to allow it at top level. The standard library documentation states that Result is annotated with #[must_use], so a Result that is neither bound nor used causes a compiler warning.

Why it matters

Exception-based code lets a failure travel upward invisibly; the signature of a Python function says nothing about what it raises. In Rust the possibility of failure is in the return type, the compiler refuses to let it be forgotten, and the same machinery covers absent values, which removes the None-returned-unexpectedly class of bugs. Panics exist but are for invariants that input cannot violate, not for expected failures.

How to apply

• Return Result from anything that touches I/O, parsing or user data; return Option for lookups where absence is normal.
• Define one error enum per crate or module with a variant per cause, implement std::error::Error and Display, and implement From for the underlying errors so ? converts automatically; crates such as thiserror generate this boilerplate.
• In application code an opaque error type carrying context (as the anyhow crate provides) is often enough; libraries should expose typed errors that callers can match on.
• Reserve unwrap and expect for tests and for cases where the invariant is stated in the expect message.
• Use combinators for short pipelines and match when the branches do different things.

Pitfalls

? inside a closure applies to the closure, not to the outer function. Converting everything to Box<dyn Error> early loses the ability to match on causes. let _ = fallible(); silences the must-use warning and drops the error. Mixing Option and Result in one chain needs ok_or or transpose.

Which errors may use bare From

Automatic conversion through From keeps whatever the inner error says and nothing more. That is enough for errors that already name their subject (a parse error with a position, a client error with the URL). It is not enough for std::io::Error, which carries neither the path nor the operation, so ? with From<io::Error> yields 'No such file or directory' with no file named. For those, add the context at the call site: a thiserror variant such as #[error("reading {path}")] Io { path: PathBuf, #[source] source: std::io::Error } filled through map_err, or in application code anyhow's .with_context(|| format!("reading {}", path.display())). Rule of thumb: one From impl per error type that is self-describing; map_err or with_context for every I/O call.