Using Rust's ? Operator for Clean Error Propagation: An Architecture Note

Requirements

When designing fallible Rust code we need a mechanism that:

1. Propagates errors from fallible operations without writing repetitive match or if let boilerplate.
2. Preserves the original error type so callers can inspect, transform, or abort based on the specific error.
3. Allows the caller to decide whether to handle, map, or let the error bubble up further.

Smallest Suitable Design

The idiomatic solution is to have every fallible function return Result where E implements std::error::Error (or is a custom error type). Inside the function, the ? operator is applied to each fallible call:

fn read_config(path: &str) -> Result<Config, io::Error> {
    let mut file = File::open(path)?;          // early return on Err
    let mut contents = String::new();
    file.read_to_string(&mut contents)?;      // early return on Err
    let cfg: Config = toml::from_str(&contents)?; // early return on Err
    Ok(cfg)
}

The operator performs two actions:

• If the operand is Err(e), it returns Err(e) from the enclosing function (early return).
• If the operand is Ok(t), it unwraps t and execution continues.

Trust/Data Boundaries

At each module boundary the function’s return type establishes a contract:

• The callee signals failure by returning Err; the caller trusts that any Err will be propagated unless explicitly matched.
• This creates a clear data‑flow boundary: errors cannot cross the boundary silently; they must be accounted for in the caller’s Result handling.

Operational Checks

Rust’s #[must_use] attribute on Result ensures that ignoring a Result produces a compiler warning. With #![deny(unused_must_use)] the warning becomes an error, guaranteeing that error propagation is not accidentally silenced.

Failure Modes

• Silenced errors: If the unused_must_use lint is disabled or overridden with #[allow(unused_must_use)], a caller may drop the Result after ?, causing the error to be lost.
• Control‑flow opacity: Deeply nested ? calls can make it difficult to see where early returns occur, especially in long functions.
• FFI/safety concerns: When crossing an unsafe or FFI boundary, the error type must be FFI‑safe; otherwise a panic across the boundary leads to undefined behavior.

Conditions That Would Change the Design

• If the codebase required zero‑cost error handling without any runtime overhead, one might replace Result with a custom enum that encodes success/failure without allocation, but the ? operator would still be applicable.
• If the project adopted a convention of using exceptions (e.g., via std::panic) for error propagation, the ? operator would be replaced by catch_unwind boundaries, which is uncommon in Rust.
• If the error type needed to carry contextual information (like backtraces) that cannot be cheaply cloned, a design using anyhow::Error or a custom error wrapper might be preferred, while still using ? for propagation.

Example Implementation

The following snippet shows a minimal library function that reads a JSON file, parses it, and returns a strongly typed struct. It demonstrates the ? operator, error‑type preservation, and the must_use check.

use std::fs::File;
use std::io::{self, Read};
use serde_json::Value;

/// Loads a JSON file and returns the parsed value.
/// Returns `io::Error` for I/O problems or `serde_json::Error` for parsing issues.
fn load_json(path: &str) -> Result<Value, Box<dyn std::error::Error>> {
    let mut file = File::open(path)?;               // ? on io::Result
    let mut contents = String::new();
    file.read_to_string(&mut contents)?;            // ? on io::Result
    let json: Value = serde_json::from_str(&contents)?; // ? on serde_json::Result
    Ok(json)
}

fn main() -> Result<(), Box<dyn std::error::Error>> {
    // Intentionally ignore the Result to see the lint warning.
    load_json("missing.json"); // warning: unused `Result` that must be used
    Ok(())
}

Verification Steps (to be performed by the reader)

1. Compile with lint enabled: In the project root run cargo check -- -W unused_must_use. You should see a warning similar to "unused `Result` that must be used".
2. Inject an error: Change the path to a non‑existent file and call the function from a test:

#[test]
fn load_json_returns_err_on_missing_file() {
    let res = load_json("definitely_does_not_exist.json");
    assert!(res.is_err());
}

Running cargo test should show the test passing, confirming that the function returns early with the error value.

1. Override the lint: Add #[allow(unused_must_use)] above the call in main and re‑run cargo check. The warning disappears, demonstrating that the check is lint‑based and can be silenced when intentional.

Limitations

• The ? operator only works with types that implement FromResidual for the enclosing function’s error type. If you need to map between unrelated error types, you must use map_err or a custom conversion trait.
• In very large functions, a chain of ? can obscure the exact point where an early return occurs. Extracting fallible sections into helper functions improves readability.
• When using ? in unsafe blocks or FFI wrappers, ensure the error type is #[repr(C)] and does not contain Rust‑specific layout that could violate ABI guarantees.

Practical Way to Check the Result

After any change that introduces or removes a ? call, run:

cargo check -- -W unused_must_use

If the build succeeds without warnings, all Result values produced by ? are being used. If a warning appears, either handle the error or explicitly annotate the call site with #[allow(unused_must_use)] after confirming the intentional discard.