Option and Result typing practice

Why these two types dominate your keystroke count

In a language with exceptions the failure path is usually invisible: you write the happy path, and a try block somewhere far away catches the rest. In Rust the failure path lives in the type, so it appears in the signature, then in the body, then at the call site. A single fallible operation can produce Result<T, E> in the return type, ? at the call, and a match or a combinator wherever the error is finally handled.

That changes what practice should target. These are not tokens you meet occasionally and look up when needed — they are load-bearing. A quarter-second pause before .ok_or_else( is a quarter-second you pay dozens of times a day.

The token inventory

Match first, combinators second

Both functions below do the same thing. The first is what most people write while learning; the second is what the same code becomes once the combinators are automatic.

fn parse_count(input: &str) -> Result<i32, String> {
    match input.parse::<i32>() {
        Ok(value) => Ok(value),
        Err(_) => Err("invalid count".to_string()),
    }
}

fn parse_count(input: &str) -> Result<i32, String> {
    input.parse::<i32>().map_err(|_| "invalid count".to_string())
}

Practise them in that order. The combinator version is shorter to type but harder to recall, because the method name carries the control flow that the match version puts on screen. Drilling the explicit form first gives you something to map the combinators onto.

The question mark, and where it stops working

The ? operator returns early on failure and unwraps on success. It is the highest-leverage token in Rust error handling and the one with the sharpest edge: it only compiles when the error type of the expression converts into the error type of the function.

fn parse_pair(input: &str) -> Result<(i32, i32), std::num::ParseIntError> {
    let mut parts = input.split(',');
    let left = parts.next().unwrap_or("0").trim().parse::<i32>()?;
    let right = parts.next().unwrap_or("0").trim().parse::<i32>()?;
    Ok((left, right))
}

When the error types differ you need a From implementation — and once it exists, ? performs the conversion for you. That is why the Error Handling pack drills impl From<ParseIntError> for AppError alongside the operator itself: they are one skill, not two.

Choosing the right fallback

Four methods do almost the same job, and choosing between them is a decision you make mid-keystroke. Getting them into your fingers means getting the distinction into your head first.

raw.unwrap_or(8080)                       // eager: builds the default every time
raw.unwrap_or_else(|| expensive())        // lazy: only on the None path
raw.ok_or_else(|| "missing".to_string())  // Option -> Result, with a reason
raw.expect("port must be set")            // panics, with a message you chose

Use .unwrap_or( for cheap constants, .unwrap_or_else( when the default costs anything to build, .ok_or_else( when a caller needs to know why, and .expect( only where failure genuinely is a bug.

Frequently asked questions

What is the difference between Option and Result in Rust?

Option<T> models a value that may be absent: it is either Some(value) or None. Result<T, E> models an operation that may fail: it is either Ok(value) or Err(error). The practical difference is information — Option tells you nothing was there, Result tells you why. Convert with .ok_or_else() when a caller needs the reason, and .ok() when it does not.

What does the ? operator actually do?

On Ok or Some it unwraps the value and execution continues. On Err or None it returns from the enclosing function immediately, converting the error type through the From trait if needed. It is shorthand for a match that returns early, which is why it only works inside a function that itself returns Option or Result.

Why is unwrap_or_else harder to type than unwrap_or?

It is sixteen characters against eleven, it contains two underscores rather than one, and it is followed by a closure rather than a plain value, so the keystroke pattern continues past the parenthesis with a pipe character. People who mistype it usually produce the shorter method, which still compiles and silently changes when the default is evaluated.

Should I ever use unwrap in real code?

In tests, prototypes, and cases where failure genuinely indicates a bug, yes. In library code and anything handling external input, prefer expect with a message explaining the invariant, or propagate with ?. The habit worth building at the keyboard is reaching for ? first: it is shorter to type than unwrap and almost always the better answer.

Keep reading

• Enum and match practice

  Option and Result are enums. Match is how you take them apart — drill it next.

• Rust typing practice: the full method

  Where Option and Result sit in the recommended order, and why.

• Collections and DSA practice

  Where Option appears constantly: .get(), .pop(), .next(), and every tree node.