Walk through refactoring an `if-else` chain of `instanceof` + cast into a pattern switch. What are the pitfalls (dominance, fall-through, null) to watch for?

## The starting point A common pre-pattern idiom branches on runtime type with `instanceof` and a cast: ```java String format(Object o) { if (o instanceof Integer i && i > 0) { return "positive int " + i; } else if (o instanceof Integer i) { return "non-positive int " + i; } else if (o instanceof String s) { return "string " + s; } else if (o == null) { return "null"; } else { return "other"; } } ``` (`instanceof Integer i` is *pattern* `instanceof`: it tests the type and binds `i` if it matches.) ## Step-by-step refactor **1. Switch over the value.** `switch (o) { ... }`. **2. Each `instanceof` branch → a `case` with a type pattern.** Drop the explicit cast; the binding gives you a typed variable: ```java case String s -> "string " + s; ``` **3. Extra conditions → guards.** `if (o instanceof Integer i && i > 0)` becomes: ```java case Integer i when i > 0 -> "positive int " + i; ``` **4. Port the null branch.** The `else if (o == null)` cannot be expressed by any type pattern (type patterns never match null), and a switch throws NPE on null by default — so add an explicit `case null`. **5. Port the final `else` → `default`.** Result: ```java String format(Object o) { return switch (o) { case null -> "null"; case Integer i when i > 0 -> "positive int " + i; case Integer i -> "non-positive int " + i; case String s -> "string " + s; default -> "other"; }; } ``` ## Pitfall 1: dominance and ordering Cases are matched **top to bottom; first match wins.** So: - The **guarded** `case Integer i when i > 0` must precede the **unguarded** `case Integer i`; otherwise the unguarded one *dominates* (catches all integers first) and the guarded case is unreachable — a **compile error**. - A **subtype** case must precede a **supertype** case (e.g. `case ArrayList<?> a` before `case List<?> l`), for the same reason. - The compiler enforces this by rejecting dominated (unreachable) cases. ## Pitfall 2: fall-through Use the **arrow form** (`case L -> ...`). It does not fall through and scopes bindings to the branch. The legacy **colon form** (`case L:`) falls through unless you `break`, and mixing it with pattern bindings creates subtle scope/flow bugs — avoid it for pattern switches. ## Pitfall 3: null semantics changed The `if`-ladder usually handles null in some branch (often the final `else`). A switch does **not**: null throws NPE unless you add `case null` (or `case null, default`). Forgetting this silently changes behavior from "handled" to "throws" — port the null branch deliberately. ## Pitfall 4: exhaustiveness As a switch *expression*, it must be exhaustive. Add a `default` for open types. If `o`'s type is **sealed**, prefer covering every permitted subtype and **omitting default**, so adding a future subtype forces a recompile rather than silently hitting default. ## Benefits realized - No manual casts (bindings are pre-typed). - Conditions are colocated with their type via guards. - Completeness is compiler-checked. - Shorter, flatter, and easier to read than the `if` ladder. ## Deriving an answer Map each `instanceof`-branch to a `case` type pattern (cast disappears), `&&` conditions to `when` guards, order specific/guarded before general (dominance), use arrow form (no fall-through), add `case null` because switch NPEs on null, and finish with a default or full sealed coverage for exhaustiveness.