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
| 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 |