In an exhaustive sealed switch with no default, how are null and an unexpected runtime subtype handled? Explain case null and MatchException.

## Two distinct 'edge' inputs An exhaustive sealed switch promises to handle every value of the sealed type. But two inputs sit outside the normal subtype enumeration and deserve their own treatment: **null** and **an unknown subtype appearing at runtime**. ## null Historically, `switch` throws `NullPointerException` if the selector is `null` — it tries to evaluate the selector and dereference it. This is unchanged for pattern switches: **exhaustiveness checking deliberately ignores null**, treating it as a separate axis. So: ```java String describe(Shape s) { return switch (s) { // exhaustive over Circle/Square case Circle c -> "circle"; case Square sq -> "square"; }; } ``` If `s` is null, this throws NPE before any case matches. To handle null gracefully you add an explicit label: ```java return switch (s) { case null -> "none"; // explicit null handling case Circle c -> "circle"; case Square sq -> "square"; }; ``` You may also combine `case null, default -> ...` to fold null into the default branch. Importantly, adding `case null` does *not* change whether the switch is exhaustive over the real subtypes — it's orthogonal. ## The hidden default and `MatchException` When you write a sealed switch with **no `default`** that the compiler accepts as exhaustive, you might assume the bytecode has no fallback. It does. The compiler inserts a **synthetic `default`** that throws **`java.lang.MatchException`** (introduced with pattern matching). Why is this needed if the switch is 'exhaustive'? Because exhaustiveness is proven against the permitted subtypes **as known when this switch was compiled**. Java supports **separate compilation**: the sealed type `Shape` and the consumer with the switch are different `.class` files that can be compiled and deployed at different times. Suppose `Shape` is later recompiled with a new `permits ... , Triangle`, and a `Triangle` instance flows into the *old* consumer's switch that only knows `Circle`/`Square`. Without a backstop, control would fall off the end of the switch with no value to return — undefined. The synthetic default throws `MatchException` to make this **fail fast and observably** rather than silently misbehave. So `MatchException` signals a **binary incompatibility / stale consumer**, not a normal program condition. You generally do not catch it; you fix the build so all consumers are recompiled against the current sealed hierarchy. ## Putting it together — the runtime contract of 'exhaustive, no default' For `switch (s)` where `s` is a sealed type and no `default` is written: 1. `s == null` → `NullPointerException`, unless a `case null` exists. 2. `s` is one of the compile-time-known permitted subtypes → its matching case runs. 3. `s` is some other subtype not known at this switch's compile time → synthetic default throws `MatchException`. ## Practical guidance - Decide null semantics explicitly: add `case null` if null is a valid input, otherwise let the NPE document that null is illegal. - Treat a `MatchException` in logs as a deployment/versioning bug — recompile consumers against the updated sealed type. - Don't add a real `default` solely to avoid `MatchException`; that would reintroduce the silent-swallow problem the design avoids.