Option, Try, and Either: typed failure

Lesson 10 gave us the monad: flatMap sequences context-carrying steps, and a for-comprehension reads that sequence like ordinary code while the context (short-circuiting, threading) is handled for us. This lesson cashes that machinery out into the three types you will reach for every single day. The one new idea: failure can be a value with a type. Instead of a function that secretly returns null or throws, the failure rides home in the return type — and because these failure types are monads, the failures compose through the very for-comprehensions you just learned.

1 · The disease: a return type that lies

Consider this signature:

def find(id: Long): User   // looks total: "give me an id, get a User"

The type says: every Long maps to a User. The type is lying. In practice the implementation does one of two invisible things when the user is missing: it returns null (so the "User" you got back is secretly not a User at all, and your next .name throws a NullPointerException three call-frames away), or it throws an exception (so the function does not "return a User" — it abruptly transfers control somewhere you cannot see from the call site).

Both are failures of the same kind we named earlier. In Lesson 06 we called a function partial if it is undefined on some inputs; find is partial (no user for that id) but wears the costume of a total function. And in Lesson 04 we defined a referentially transparent expression as one you can replace with its value without changing meaning. You cannot substitute find(id) with "a User," because sometimes there is no value to substitute — there is a null landmine or a thrown control-flow jump. The signature hides the very thing you must handle.

The cure is a single idea: make the failure a value in the return type. Change the type so it honestly says "this might not produce an A." Then the compiler will not let the caller ignore it, the function becomes total (every input maps to some well-defined result), and — the payoff — these honest types are the monads of Lesson 10, so the failure threads through compositions automatically.

2 · Option[A] — modelling absence

Option[A] is a sum type (Lesson 06) with exactly two shapes: Some(a) holds a value of type A; None holds nothing. It models absence — "there might be no A here" — and carries no detail about why. That is its whole job.

def find(id: Long): Option[User]   // honest: maybe a User, maybe not

find(7) match {
  case Some(user) => user.name     // the value is right here, unwrapped and safe
  case None       => "unknown"     // the compiler made us handle this branch
}

The standard library already speaks Option wherever a lookup can fail. These are the total versions of partial operations:

List(1,2,3).headOption          // Some(1);  Nil.headOption == None  (head would throw)
Map("a" -> 1).get("a")          // Some(1)
Map("a" -> 1).get("z")          // None      (no exception, no null)
"42".toIntOption                // Some(42); "oops".toIntOption == None

To get a plain value out with a default, use getOrElse (never .get — see §6):

val name = find(7).map(_.name).getOrElse("anonymous")

Crucially, Option is a monad (Lesson 10): it has map (Lesson 08's functor operation) and flatMap, and any chain short-circuits on None — the moment a step produces None, the rest is skipped and the whole result is None. Mirror the lookup chain from Lesson 10 — user → account → balance, where each step might be absent:

def account(u: User): Option[Account]
def balance(a: Account): Option[Money]

val result: Option[Money] =
  for {
    u <- find(id)       // Option[User]
    a <- account(u)     // Option[Account]
    b <- balance(a)     // Option[Money]
  } yield b
// if ANY step is None, result is None — no null check written anywhere

That for is exactly the flatMap/map desugaring from Lesson 10; the "if it's missing, stop" logic lives in Option's flatMap, not in your code.

3 · Either[E, A] — a typed error channel

Option tells you that something is absent but never why. When the caller needs the reason — to show a message, to branch on the error, to log it — use Either[E, A]. It too is a two-shape sum type: Right(a: A) is the success, Left(e: E) is the failure carrying a value of type E that explains it (a message, an error enum, anything). Mnemonic: Right is "right" / correct; Left is what's left over when things go wrong.

Scala's Either is right-biased: map and flatMap operate on the Right and pass any Left through untouched. So a for-comprehension over Either short-circuits on the first Left and preserves its error value — you find out not just that it failed but precisely which step failed and why.

def parseInt(s: String): Either[String, Int] =
  s.toIntOption.toRight(s"not a number: '$s'")   // Some->Right, None->Left(msg)

def positive(n: Int): Either[String, Int] =
  if (n > 0) Right(n) else Left(s"must be positive: $n")

val good = for { n <- parseInt("42"); p <- positive(n) } yield p   // Right(42)
val bad1 = for { n <- parseInt("oops"); p <- positive(n) } yield p // Left("not a number: 'oops'")
val bad2 = for { n <- parseInt("-5");  p <- positive(n) } yield p  // Left("must be positive: -5")

Note how bad1 short-circuits at the first step — positive never runs, and the original message survives in the Left. That is the whole advantage over Option: the failure has a type and a payload, so the caller can act on it.

4 · Try[A] — capturing a thrown exception

Sometimes the failure is not yours to design — you are calling legacy or Java code that throws. Try[A] (from scala.util) captures that: Try { expr } runs expr, and if it throws, the exception becomes a value instead of unwinding the stack. Its two shapes are Success(a) and Failure(t: Throwable).

import scala.util.{Try, Success, Failure}

val parsed: Try[Int] = Try { Integer.parseInt(userInput) }  // may throw NumberFormatException

parsed match {
  case Success(n) => n
  case Failure(e) => { log(e); 0 }
}

// Try is a monad too, so it composes and short-circuits on the first Failure:
val cfg = for {
  port <- Try(Integer.parseInt(portStr))
  conn <- Try(openSocket(port))            // a throw here becomes Failure, stops the chain
} yield conn

Think of Try[A] as Either[Throwable, A] with the left side fixed to Throwable and a built-in "run this block and catch" constructor. It is the bridge at the boundary: wrap throwing code in Try at the edge of your functional core (Lesson 00) so that everything inside stays in the world of values. (Where you need a domain error rather than a raw Throwable, convert: parsed.toEither.left.map(_.getMessage) gives an Either[String, Int].)

5 · Which one, when

All three are monads, so they all compose the same way; they differ only in what the failure carries. Choose by what the caller needs to know:

A quick rule: reach for Option first (it is the lightest); upgrade to Either the moment the caller would ask "why did it fail?"; use Try only to catch a thrown exception and immediately turn it into a value.

6 · Composition and short-circuit — a worked trace

Here is parseConfig: it reads three fields from a raw map, each parse returning Either[String, T], and combines them in one for-comprehension. Because Either is right-biased, the first Left wins and the remaining steps are skipped.

final case class Config(host: String, port: Int, retries: Int)

def field(raw: Map[String,String], key: String): Either[String, String] =
  raw.get(key).toRight(s"missing field: $key")

def parseConfig(raw: Map[String,String]): Either[String, Config] =
  for {
    host    <- field(raw, "host")                              // Either[String, String]
    portS   <- field(raw, "port")
    port    <- portS.toIntOption.toRight(s"bad port: $portS")  // Either[String, Int]
    retries <- field(raw, "retries").flatMap(s =>
                 s.toIntOption.toRight(s"bad retries: $s"))
  } yield Config(host, port, retries)

One failure wins — what about reporting all of them? A for-comprehension is sequential: it threads each step's value into the next, so it must stop at the first failure (it has nothing to feed the rest). That is exactly right for dependent steps, but if you want to validate independent fields and collect every error ("port is bad AND retries is bad"), you need a different tool — an applicative, often the Validated type from the Cats library, which combines failures instead of short-circuiting. That belongs to the ecosystem; we defer the mechanism to Lesson 14. For now: for over Either = first failure wins.

Common mistakes / failure modes

Checkpoint exercise

Where this points next

We now have honest data (immutable values, Lesson 03) and honest failure (typed, composable, Lesson 11) — the full vocabulary of a value. But we have been quietly using collections and chained operations without asking how an immutable program iterates: with no mutable loop counter, how do you walk a list or build one up? Lesson 12 answers with recursion as the functional loop — structural recursion, tail recursion with @tailrec for stack safety, the accumulator pattern — and then closes a worry first raised back in Lesson 03: it introduces persistent data structures whose structural sharing makes "build a new value to update" cheap rather than wasteful, finally cashing the promise that immutability need not mean copying everything.

Interview prompts

• Why are null and thrown exceptions considered worse than a typed failure value? (§1 — they are invisible in the signature, so a function looks total while being partial; this breaks referential transparency and the failure surfaces at runtime far from its cause, with the compiler unable to force handling.)
• When would you choose Option over Either, and vice versa? (§2, §3, §5 — Option when something may be absent and the caller needs no reason; Either when the caller needs the typed why to display, log, or branch on.)
• What does it mean that Scala's Either is "right-biased," and what does a for-comprehension over it do on failure? (§3, §6 — map/flatMap act on Right and pass Left through; the comprehension short-circuits on the first Left, skips the rest, and preserves that error value.)
• How does Try relate to Either, and when is Try the right tool? (§4 — Try[A] is essentially Either[Throwable, A] with a "run-and-catch" constructor; use it to wrap code that throws, at the boundary, converting a thrown exception into a value.)
• Why is calling .get on an Option or Try an anti-pattern? (§6 mistakes — it throws on None/rethrows on Failure, reintroducing the invisible runtime failure the type existed to remove; use getOrElse/map/pattern match/for instead.)
• A for-comprehension over Either reports only the first error. How would you collect all validation errors instead? (§6 — a monadic for is sequential and must stop at the first failure; collecting all errors needs an applicative such as Cats' Validated, which combines failures — deferred to Lesson 14.)
• How do these three types connect back to Lesson 10? (§2–§4 — each is a monad: it has map (functor, Lesson 08) and flatMap, obeys the monad laws, and therefore sequences in for-comprehensions with automatic short-circuiting — the daily payoff of the abstraction.)