No null, no exceptions: Option and Result are just enums

Two sentences you will hear from people learning Rust, both wrong, and both expensive:

• “Option is Rust’s null.”
• “Result is Rust’s checked exception.”

If you carry either of those around for a few months, you will write awkward Rust and blame the language. This article is the reset. It costs ten minutes and it makes everything downstream — combinators, ?, error traits — stop looking like magic.

The actual definitions

Here they are, near enough verbatim from the standard library:

pub enum Option<T> {
    None,
    Some(T),
}

pub enum Result<T, E> {
    Ok(T),
    Err(E),
}

That is it. Two ordinary enums, defined in ordinary Rust, in a file you can open. Nothing about them is built into the compiler. You could write them yourself in six lines:

enum Maybe<T> { Nothing, Just(T) }
enum Outcome<T, E> { Fine(T), Broken(E) }

and everything except the ecosystem’s cooperation would work. They are in the prelude — that is the only special treatment. (? does lean on a trait they implement, but the trait is public and the enums are not privileged. More on that later in the track.)

Once you believe this, several things follow immediately:

• map is not a keyword. It is a method someone wrote in impl<T> Option<T>. You could write it yourself and it would be four lines.
• match is not “the Option syntax”. It is the general way to take any enum apart, and it works on yours identically.
• There is nothing to “turn off”. No mode, no exception table, no runtime cost that a flag could remove. An Option<T> is a tagged union, and for types with a spare bit pattern — references, Box, NonZeroU32 — the tag costs nothing at all: size_of::<Option<&T>>() == size_of::<&T>().

What is actually different from null

Tony Hoare called null references his “billion-dollar mistake”, and the reason is not that null exists — it is that null is a value of every type. In Java, String s might be a string, or might be nothing, and there is no syntax to say which you meant. Every method call is a bet.

Rust splits the two apart:

let name: String = get_name();          // definitely a String
let name: Option<String> = get_name();  // maybe a String, maybe nothing

Those are different types. You cannot pass one where the other is wanted; you cannot call String methods on the second without first saying what should happen when it is empty. The compiler is not being pedantic — it genuinely cannot know what you want, and neither could the reader.

The payoff is not “no more null pointer exceptions” (though it is that). The payoff is that the signature tells you. When you see

fn find_user(id: u64) -> Option<User>

you know, without reading the body, the docs or the tests, that this can come back empty, and that the compiler will make you deal with it. When you see

fn current_user() -> User

you know it cannot.

What is actually different from exceptions

An exception is invisible control flow. Any line can throw; the handler is somewhere else; the type system usually says nothing. Java’s checked exceptions were an attempt to fix that, and they failed for a reason worth understanding: they were bolted onto methods rather than values, so they could not be stored, returned, mapped over, or collected. You could only catch them, and the cheapest catch is an empty one.

Result is a value.

fn parse_port(s: &str) -> Result<u16, ParseIntError>

The failure is not a side channel — it is half the return type. Which means every ordinary thing you can do with a value, you can do with a failure:

let results: Vec<Result<u16, _>> = inputs.iter().map(|s| parse_port(s)).collect();
let successes: Vec<u16> = results.into_iter().flatten().collect();

Store them in a vector. Send one down a channel. Keep one in a struct. Turn a list of results into a result of a list. None of that has an equivalent with exceptions, because an exception is not a thing you have, it is a thing that happens to you.

The other half of the difference is that you cannot ignore it silently. Result is marked #[must_use], so dropping one is a warning — and in this course’s grading, a build failure. The equivalent of an empty catch block has to be written out loud:

let _ = might_fail();   // "yes, I looked at this and chose to ignore it"

A reviewer can grep for that. Nobody can grep for a catch you never wrote.

fn load() -> Result<Config, ConfigError> {
    let text = read_file("config.toml")?;
    let port = parse_port(&text)?;
    Ok(Config { port })
}

The one thing to be careful about right now

You will very quickly meet this:

let n: i32 = maybe_number.unwrap();

unwrap takes the Some out, and panics — crashes the program — if there is nothing there. It exists because sometimes you genuinely know, and because examples need to be short.

Treat it, for now, as a placeholder that means “I have not decided what to do here yet.” Every use of it in a code sample you find online is a decision the author deferred, usually to keep the example readable. There is a whole item later in this track about when it is legitimate and what a good expect message says. Until then: if you find yourself typing .unwrap(), the interesting question is what should happen in the empty case, and the answer is almost never “crash”.

Where this goes

Everything in the rest of this track is a consequence of “they are just enums”:

• Taking them apart is pattern matching, because that is how you take any enum apart.
• map, and_then, ok_or are ordinary generic methods, and knowing which one to reach for is vocabulary, not syntax.
• ? is a return plus a From conversion, both of which you can already read.
• Your own error types are enums too, and once they implement two small traits they compose with everybody else’s.

No part of it is a special language mode. It is types, and the compiler holding you to them.