Functional error handling treats errors as explicit values in the type system rather than using exceptions, enabling composable, type-safe error propagation without hidden control flow. Core patterns include Result/Either types (encoding success or failure as data), Option/Maybe types (representing absence without null), and Railway-Oriented Programming (visualizing error paths as parallel tracks that never intersect). These patterns make errors first-class citizens, enforce handling at compile-time, and enable powerful combinators like flatMap, map, and fold for chaining fallible operations. The key mental model: errors become return values, not exceptional jumps — transforming unpredictable crashes into predictable, testable data flows.
What This Cheat Sheet Covers
This topic spans 12 focused tables and 77 indexed concepts. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.
Table 1: Core Error Types
These are the data types that carry a failure instead of throwing it — the building blocks everything else here sits on top of. Reach for Result/Either when an operation can fail with a meaningful error, Option/Maybe when a value might simply be absent, and Validated when you want to collect every error rather than stop at the first. The richer wrappers (Try, Effect) extend the same idea to exception-throwing or side-effecting code.
| Type | Example | Description |
|---|---|---|
Result<User, DbError> | • Represents success ( Ok<T>) or failure (Err<E>) with typed error• forces explicit handling of both paths | |
Either<ValidationError, Int> | • Generic disjoint union type where Left conventionally holds error, Right holds success• right-biased for ease of chaining | |
Option<String> yielding Some("value") or None | • Represents presence ( Some) or absence (None) of a value• eliminates null-pointer errors by making absence explicit in the type |