How do record patterns combine with switch and sealed types, including exhaustiveness, guards, and dominance ordering?

## Record patterns as case labels Java's `switch` evolved from constant-matching into **pattern matching**. A case label may be a **type pattern** (`case Point p`) or a **record pattern** (`case Point(int x, int y)`). With record patterns each branch tests the shape and binds the components it needs: ```java switch (shape) { case Point(var x, var y) -> handlePoint(x, y); case Line(Point(var x1, var y1), Point(var x2, var y2)) -> handleLine(x1, y1, x2, y2); default -> handleOther(); } ``` ## Sealed types and exhaustiveness A **sealed** type restricts which classes may extend/implement it via a `permits` clause, so the compiler knows the *complete* set of subtypes. Example: ```java sealed interface Shape permits Point, Line, Circle {} ``` When a `switch` **expression** (or a switch statement requiring completeness) is over a sealed type, the compiler verifies **exhaustiveness**: are all permitted subtypes covered by the case labels? If yes, **no `default` is required**. This is powerful: add a new permitted subtype (say `Triangle`) and every non-exhaustive switch over `Shape` becomes a **compile-time error**, forcing you to handle it — far safer than a silent runtime `default`. Note a subtlety: a *record pattern* with nested type patterns is not always provably total over the type, because an inner pattern could fail (e.g. a nested reference type test). The compiler considers a case to cover a subtype only when it can prove the match always succeeds for that subtype. ## Guards: the `when` clause A **guarded pattern** adds a boolean condition with `when`: ```java case Point(var x, var y) when x == y -> "on the diagonal"; case Point(var x, var y) -> "off the diagonal"; ``` The case matches only if the pattern matches **and** the guard is true. Because a guard can be false, a guarded case is **not** considered exhaustive on its own — you typically follow it with an unguarded fallback for the same shape. The unguarded case must come **after** the guarded one (specific before general). ## Dominance ordering Case labels are tried top-to-bottom. A label **dominates** a later one if everything the later one matches, the earlier one already matches. The compiler rejects a switch where an earlier label dominates a later, reachable label (the later case would be **unreachable**). Practical rules: more specific record patterns / guarded cases come first; broader type patterns and `default` come last. For example `case Shape s` (or `default`) must not precede `case Point(...)`. ## null and MatchException - By default a pattern switch **throws NullPointerException** on a null selector unless you add `case null` (or `case null, default`). So `case null -> ...` handles null explicitly. - At **runtime**, if the selector is non-null and matches no label in a switch the compiler treated as exhaustive only via the sealed contract, but the actual runtime class falls outside (e.g. separate compilation skew where a new subtype appears), a **MatchException** is thrown rather than silently falling through. This makes incomplete coverage fail loudly. ## Why this matters Record patterns + sealed types + switch give Java **algebraic-data-type style** programming: model a closed set of shapes, then handle each shape's structure in one exhaustive, compiler-checked switch. It replaces visitor boilerplate and instanceof chains with declarative, total, refactor-safe code.