What does it mean for a switch over a sealed type to be exhaustive, and how does a sealed hierarchy let the compiler verify exhaustiveness without a default arm?

## The terms, from first principles **A `switch`** picks one branch of code based on a value. A **`switch` *expression*** (Java 14+) is a switch that *produces a value*, e.g. `int n = switch (shape) { ... };`, unlike a `switch` *statement* that just runs code. Because an expression must yield a value for *every* possible input, the compiler insists it be **exhaustive** — it must cover every input — otherwise some input would leave the expression with no value to return. **A sealed type** (finalized in Java 17) is a class or interface marked `sealed` with a `permits` clause listing exactly which types may directly extend or implement it. Example: `sealed interface Shape permits Circle, Square, Triangle {}`. No other type — anywhere, even in another file — can be a direct subtype of `Shape`. The set of subtypes is therefore **closed** and **known at compile time**. **Exhaustiveness** means: the set of `case` labels covers every value the selector could take. For an `int` selector that is practically impossible (4 billion values), so you need `default`. But for a sealed type, the universe of values is just "instances of the permitted subtypes" (plus `null`). The compiler enumerates the permitted subtypes and checks each is matched by some case. ## Why a sealed hierarchy enables it Before sealed types, any class could be subclassed by anyone, so the compiler could never know it had seen *all* possible subtypes — it had to assume an unknown subtype might appear at runtime, forcing a `default`. `sealed` removes that uncertainty: the compiler reads the `permits` clause, sees the *complete* list, and if your switch has a case for each one, it concludes no other type is reachable. Exhaustiveness is proven, and **no `default` is required**. ```java sealed interface Shape permits Circle, Square {} record Circle(double r) implements Shape {} record Square(double s) implements Shape {} double area(Shape sh) { return switch (sh) { // no default needed case Circle c -> Math.PI * c.r() * c.r(); case Square sq -> sq.s() * sq.s(); }; } ``` ## Why omit `default` on purpose This is the key engineering point. Suppose you add `record Triangle(...) implements Shape {}` to the `permits` list. Every switch that lacked a `Triangle` case now **fails to compile** with "the switch statement/expression does not cover all possible input values." The compiler hands you a to-do list of every place to update. Had you written a catch-all `default -> ...`, the code would still compile and the new `Triangle` would silently fall into `default` — a latent bug. So you trade the convenience of `default` for a compile-time guarantee that the hierarchy and its consumers stay in sync. ## Details and edge cases - **`null`:** by default `switch` throws `NullPointerException` on a null selector. Pattern switches may add `case null` to handle it; exhaustiveness checking treats null separately. Without `case null`, an exhaustive switch is still considered exhaustive — null just NPEs as usual. - **Statements vs expressions:** a `switch` *expression* is *always* required to be exhaustive. A `switch` *statement* using the new pattern/null labels is *also* checked for exhaustiveness; a legacy statement (e.g. plain `int`/`String` with no patterns) is not. - **Synthetic default / `MatchException`:** when a switch is exhaustive without `default`, the compiler may insert a hidden default that throws `MatchException` to cover the gap if, at runtime, a separately-compiled subtype appears that wasn't known at compile time (binary incompatibility). You never write this; it is a safety backstop. - **`non-sealed` subtypes:** a permitted subtype can be `non-sealed`, reopening it for further extension. Covering the `non-sealed` subtype's case still satisfies exhaustiveness because any deeper subtype *is-a* that permitted type. - **Enums** had a similar (weaker) story: a switch over an enum covering all constants in an expression is exhaustive too; sealed types generalize this to arbitrary class hierarchies.