How does exhaustiveness work in a pattern switch, and how do sealed types let you write a switch with no default?

## What exhaustiveness means **Exhaustiveness** is the property that a switch handles **every possible value** the selector could take. Java requires it for: - every **switch expression** (a switch that produces a value, e.g. `var x = switch(...) {...};`), and - every **switch statement that uses patterns**. The compiler verifies it; a non-exhaustive switch is a compile error. The reason is safety: an expression must always yield a value, so there can be no unhandled input. ## Making an open type exhaustive For a selector typed as something open like `Object`, there are infinitely many possible runtime types, so you cannot enumerate them. You make the switch exhaustive with a **`default`** branch (or `case null, default`), which catches everything not otherwise matched. ## Sealed types: a closed set of possibilities A **sealed** type (class or interface) explicitly restricts which other classes may extend or implement it: ```java sealed interface Shape permits Circle, Square, Triangle {} record Circle(double r) implements Shape {} record Square(double s) implements Shape {} record Triangle(double b, double h) implements Shape {} ``` Because `Shape` *permits* exactly `Circle`, `Square`, and `Triangle`, the compiler knows the **complete** set of subtypes. (A `record` is a compact immutable data class; here they're the variants.) ## Exhaustive switch with no default Now a switch over `Shape` is exhaustive once it covers all three permitted subtypes — **no default needed**: ```java double area(Shape s) { return switch (s) { case Circle c -> Math.PI * c.r() * c.r(); case Square sq -> sq.s() * sq.s(); case Triangle t -> 0.5 * t.b() * t.h(); // no default required — all permitted types covered }; } ``` ## Why omitting default is a feature, not laziness If you later add a fourth variant: ```java sealed interface Shape permits Circle, Square, Triangle, Hexagon {} ``` the `area` switch is **no longer exhaustive**, so it **fails to compile** until you add a `case Hexagon`. The compiler thus points you at *every* switch that must be updated — a refactoring safety net. Had you written a `default -> ...`, the new `Hexagon` would silently fall into `default`, hiding the omission and likely producing a bug. So when switching over a sealed type, **prefer no default** to keep the exhaustiveness check meaningful. (Use a default only when you genuinely want a deliberate catch-all.) ## MatchException and separate compilation Classes can be compiled separately, so at runtime a sealed hierarchy might have changed since the switch was compiled (e.g. a recompiled `Shape` with a new subtype, but the switch not recompiled). To stay safe, the compiler inserts a synthetic fallback that throws **`MatchException`** if no case matches at runtime. You normally never see it; it guarantees the switch can't silently "fall off the end." ## null and exhaustiveness Exhaustiveness over a reference type does not, by itself, include `null` — null still throws NPE unless you add `case null`. So "covers all subtypes" means all non-null values; null is handled separately (see the null question). ## Deriving an answer Exhaustive = handles every input, compiler-enforced for expressions/pattern switches. Open type → need default. Sealed type → compiler knows all permitted subtypes, so covering each makes it exhaustive without default; omitting default turns "added a new variant" into a compile error instead of a silent bug. A hidden MatchException guards the separate-compilation edge case.