Rust Error Handling Practice: Result, Option, ? Operator

The most common first error. You used ? in a function that returns ():

// WRONG: main returns () but uses ?
// fn main() {
//     let config = std::fs::read_to_string("config.toml")?;  // error[E0277]
// }

// RIGHT: return Result from main
fn main() -> Result<(), std::io::Error> {
    let config = std::fs::read_to_string("config.toml")?;
    println!("{config}");
    Ok(())
}

For application entry points, Box<dyn std::error::Error> accepts any error type:

fn main() -> Result<(), Box<dyn std::error::Error>> {
    let config = std::fs::read_to_string("config.toml")?;
    let port: u16 = config.trim().parse()?;  // different error type — still works
    Ok(())
}

? unwraps Ok/Some and returns early with Err/None. It replaces verbose match blocks:

// Without ?: verbose match
fn read_username() -> Result<String, std::io::Error> {
    let f = std::fs::read_to_string("username.txt");
    let username = match f {
        Ok(s) => s,
        Err(e) => return Err(e),
    };
    Ok(username.trim().to_string())
}

// With ?: concise
fn read_username() -> Result<String, std::io::Error> {
    let username = std::fs::read_to_string("username.txt")?;
    Ok(username.trim().to_string())
}

? also works with Option — returns None early if the value is absent:

fn first_word(s: &str) -> Option<&str> {
    let end = s.find(' ')?;  // None if no space found
    Some(&s[..end])
}

fn longest_line(text: &str) -> Option<&str> {
    let mut longest: Option<&str> = None;
    for line in text.lines() {
        let current = longest.unwrap_or("");
        if line.len() > current.len() {
            longest = Some(line);
        }
    }
    longest
}

You cannot mix ? on Result and Option in the same function. Convert with .ok() (Result → Option) or .ok_or() (Option → Result). If you're coming from Python, the approach to errors is fundamentally different; see Python vs Rust error handling compared for a side-by-side breakdown.

When ? produces a different error type than your function returns, the compiler rejects it:

// WRONG: io::Error vs ParseIntError
// fn load_port() -> Result<u16, std::io::Error> {
//     let s = std::fs::read_to_string("port.txt")?;  // io::Error — OK
//     let port = s.trim().parse::<u16>()?;             // ParseIntError — error[E0277]
//     Ok(port)
// }

// RIGHT Option 1: map_err to convert inline
fn load_port() -> Result<u16, String> {
    let s = std::fs::read_to_string("port.txt")
        .map_err(|e| format!("read failed: {e}"))?;
    let port = s.trim().parse::<u16>()
        .map_err(|e| format!("bad port: {e}"))?;
    Ok(port)
}

// RIGHT Option 2: Box<dyn Error> accepts any error type
fn load_port_boxed() -> Result<u16, Box<dyn std::error::Error>> {
    let s = std::fs::read_to_string("port.txt")?;
    let port = s.trim().parse::<u16>()?;
    Ok(port)
}

Chained ? calls propagate the inner error as-is, losing where the failure happened. Add context with map_err:

fn load_config() -> Result<Config, String> {
    let text = std::fs::read_to_string("config.toml")
        .map_err(|e| format!("failed to read config: {e}"))?;
    let port: u16 = text.lines().next().unwrap_or("0")
        .parse()
        .map_err(|e| format!("failed to parse port: {e}"))?;
    Ok(Config { port })
}

For application code, the anyhow crate provides .context() which is more ergonomic. For libraries, define concrete error types so callers can match on variants. For a printable reference of all these combinators, see the error handling cheat sheet.

Both convert Option to Result, but differ in when the error value is created:

let name: Option<&str> = Some("Alice");

// ok_or: error value computed eagerly (always created)
let result = name.ok_or("name is required");

// ok_or_else: error value computed lazily (only on None)
let result = name.ok_or_else(|| format!("name missing at line {}", line_num));

Use ok_or for cheap static errors. Use ok_or_else when the error involves allocation or computation.

Avoid match spam with these combinators:

unwrap() and expect() both panic on error. They are not always wrong:

• Tests: .unwrap() is fine — a panic is a test failure
• Prototyping: .unwrap() keeps code short while exploring
• Provably safe: .expect("reason") when you can prove the call never fails

// Fine: "1" is always a valid u32
let one: u32 = "1".parse().expect("literal '1' is always valid");

// Fine in tests
#[test]
fn test_parse() {
    let result = parse_config("valid input").unwrap();
    assert_eq!(result.port, 8080);
}

In production, prefer ? for propagation. panic! is for bugs and impossible states, not for bad user input.

For libraries or complex applications, define an error enum:

use std::fmt;

#[derive(Debug)]
enum AppError {
    Io(std::io::Error),
    Parse(std::num::ParseIntError),
    Config(String),
}

impl fmt::Display for AppError {
    fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
        match self {
            AppError::Io(e) => write!(f, "IO error: {e}"),
            AppError::Parse(e) => write!(f, "parse error: {e}"),
            AppError::Config(msg) => write!(f, "config error: {msg}"),
        }
    }
}

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

impl From<std::num::ParseIntError> for AppError {
    fn from(e: std::num::ParseIntError) -> Self { AppError::Parse(e) }
}

// Now ? converts both error types automatically
fn load_port() -> Result<u16, AppError> {
    let s = std::fs::read_to_string("port.txt")?;
    let port = s.trim().parse::<u16>()?;
    Ok(port)
}

The thiserror crate generates Display and From impls from attributes, reducing this boilerplate significantly. Custom error enums with From impls are a common pattern in Rust; see structs and enums for the underlying enum definition syntax.

• The Rust Book: Error Handling — panic vs recoverable errors
• The Rust Book: Propagating Errors — the ? operator
• std::result::Result — full combinator API
• std::option::Option — ok_or, ok_or_else, and more