What are the special unreachability rules for catch blocks and checked exceptions?

## Background: checked vs. unchecked exceptions Java exceptions split into two families: - **Checked exceptions** (subclasses of `Exception` but not `RuntimeException`, e.g. `IOException`): the compiler *tracks* these. A method must declare them with `throws` or handle them. The compiler knows exactly which checked exceptions a piece of code can produce. - **Unchecked exceptions** (`RuntimeException` and its subclasses, like `NullPointerException`) and **errors** (`Error`, like `OutOfMemoryError`): these can be thrown *implicitly, anywhere* — a null dereference, a division by zero, the JVM running out of memory. The compiler does not track them. ## The catch reachability rule The JLS says a `catch` clause is **unreachable (a compile error)** if it is impossible for the try block to throw a *checked* exception that is assignable to the caught type. In plain terms: you cannot catch a checked exception that the try block provably cannot throw. ```java try { System.out.println("no IO here"); } catch (IOException e) { // ERROR: IOException can never be thrown by the try } ``` Nothing in the try declares or throws `IOException`, so catching it is unreachable. This rule forces your catch clauses to correspond to exceptions that can genuinely occur, preventing dead handlers and copy-paste mistakes. ## Why unchecked types are always allowed Because unchecked exceptions and errors can arise *anywhere*, the compiler can never prove they won't be thrown. So these catches are **always reachable**: ```java try { trivial(); } catch (RuntimeException e) {} // always OK catch (Error e) {} // always OK catch (Exception e) {} // OK (covers unchecked subtypes too) catch (Throwable t) {} // always OK ``` Note the subtlety: `catch (Exception e)` is allowed even on a try that throws no checked exception, because `RuntimeException extends Exception`, and runtime exceptions can occur anywhere. Only catching a *specific checked* type the try can't throw is the error. ## Related rule 1: ordering of catch clauses A catch for a subtype placed **after** a catch for its supertype is unreachable, because the earlier, broader catch already handles it: ```java try { readFile(); } catch (Exception e) {} // catches everything first catch (IOException e) {} // ERROR: already caught by Exception above ``` Most specific exceptions must come first. ## Related rule 2: multi-catch Java 7+ allows `catch (A | B e)` to handle several types in one block. The rule: the alternatives must be **disjoint** — none may be a subtype of another: ```java catch (IOException | Exception e) {} // ERROR: IOException is a subtype of Exception ``` If one already covered the other, listing both is redundant and rejected. ## Why this matters These rules make the type system enforce that every handler can actually fire. Combined with checked-exception tracking, they catch a whole class of bugs at compile time: handlers for impossible exceptions, shadowed handlers, and redundant multi-catch alternatives — all surfaced as unreachable/illegal-catch errors rather than dead code that silently never runs.