Why must a more specific exception type be caught before its supertype, and what happens if you reverse the order?

## The setup Exception classes form an inheritance tree. For example: `Exception` is the parent of `IOException`, which is the parent of `FileNotFoundException`. Saying a subtype **IS-A** supertype means a `FileNotFoundException` object is simultaneously an `IOException` and an `Exception`. When the JVM matches a thrown exception against catch clauses, it goes **top to bottom** and picks the **first clause whose declared type is assignable from the thrown object's type** (i.e. the thrown type is the same as, or a subclass of, the clause's type). Crucially: the first match wins and the rest are skipped. ## Why order matters Consider two clauses, a supertype and a subtype: ```java try { ... } catch (Exception e) { // supertype FIRST } catch (IOException e) { // subtype SECOND } ``` Think about *any* `IOException` thrown in the try block. Because an `IOException` **IS-A** `Exception`, the very first clause `catch (Exception e)` is assignable from it and matches. The second clause `catch (IOException e)` is therefore **never reachable** — there is no exception value that could ever reach it, because anything it could catch was already caught above. The Java Language Specification calls this out: a catch clause is a compile error if its exception type is a subtype of (or the same as) the type of an earlier catch clause in the same try statement. The compiler emits **"exception IOException has already been caught"** and the code does not compile. This is a hard guarantee, not a warning — Java refuses to let you write a provably dead handler. ## The correct ordering List clauses from **most specific to most general**: ```java try { ... } catch (FileNotFoundException e) { // most specific } catch (IOException e) { // broader } catch (Exception e) { // most general (catch-all) } ``` Now each thrown exception finds its narrowest matching handler first, and every clause is reachable: a `FileNotFoundException` hits clause 1, a `SocketException` (another `IOException`) falls through to clause 2, and, say, a `RuntimeException` falls through to clause 3. ## The boundary of the rule The unreachable-catch rule applies **only between types on the same inheritance line**. Two *unrelated* exception types — say `IOException` and `SQLException`, where neither is a subtype of the other — can appear in **either order**, because neither shadows the other. The compiler only complains when an earlier clause already covers everything a later clause could. ## Why a compile error rather than a runtime surprise Reachability of catch clauses is fully determined by the static type hierarchy, which the compiler knows completely. So it can prove dead handlers at compile time and stop them, the same way it flags unreachable statements after a `return`. This protects you from a silent bug where you *thought* you were handling `IOException` specially but the broad clause above quietly intercepted it. ## Practical takeaway Always arrange catches narrowest-first. If you only need one broad handler, that's fine — just don't follow it with a more specific one on the same line.