How does the exception variable's type in a multi-catch interact with the methods you can call and with precise rethrow analysis?

## Two distinct ideas, often confused This question joins **(1)** what type the multi-catch variable has (and thus which methods you can call) with **(2)** the Java 7 *precise rethrow* analysis. Both shipped together but they answer different questions. ## (1) The variable's type — the least upper bound When you write `catch (A | B | C e)`, the compiler assigns `e` the **least common supertype** of A, B, and C — formally the **lub** (least upper bound) in the class hierarchy. If `IOException` and `SQLException` are the alternatives, their nearest shared ancestor is `Exception`, so `e` is of static type `Exception`. Consequence: **only members declared on that lub are callable.** ```java catch (IOException | SQLException e) { e.getMessage(); // OK — declared on Throwable/Exception e.getErrorCode(); // COMPILE ERROR — that's SQLException-only } ``` To reach a subtype-specific method you must narrow at runtime: ```java catch (IOException | SQLException e) { if (e instanceof SQLException sql) { // pattern instanceof int code = sql.getErrorCode(); } } ``` (If the lub is an *intersection* of types — possible with interfaces like `Serializable` — you can call members of all the intersected types; but the common case is a single class.) ## (2) Precise rethrow Before Java 7, this method had to declare `throws Exception`, losing precision for callers: ```java void m() throws Exception { // pre-7: forced to be broad try { dangerous(); } // dangerous() throws IOException, SQLException catch (Exception e) { cleanup(); throw e; // pre-7: compiler thinks this throws Exception } } ``` From Java 7, the compiler performs **precise rethrow analysis**: if a catch parameter is **not reassigned** in the block, then a `throw e;` is treated as throwing **only the exception types that could actually reach that catch** — derived from the `try` body — not the broad declared catch type. So: ```java void m() throws IOException, SQLException { // now precise! try { dangerous(); } catch (Exception e) { cleanup(); throw e; // analyzed as IOException|SQLException, not Exception } } ``` The key condition is **the parameter must be effectively final** (not reassigned). This is exactly why multi-catch parameters are *implicitly final* — it guarantees the analysis is sound, because the variable provably still holds the originally-caught object. ## How the two combine Together they enable the idiomatic Java 7+ pattern: **catch broadly or via multi-catch, do shared handling/cleanup, and rethrow with a precise narrow `throws`**: ```java String load() throws ParseException, IOException { try { return parse(read()); } catch (ParseException | IOException e) { metrics.increment("load.failure"); throw e; // precise: throws clause stays ParseException, IOException } } ``` Callers still see the exact checked exceptions; you didn't have to widen the signature to `throws Exception` just to share a handler. This is what the JLS/Project Coin called improving **exception transparency**. ## Edge cases & gotchas - **Reassigning the variable defeats precise rethrow.** If you do `e = new Exception();` (only possible in single-catch, since multi-catch forbids it), the rethrow falls back to the declared/assigned type. This is another reason multi-catch forces finality. - **Only checked exceptions matter for `throws`.** Unchecked (`RuntimeException`) types don't need declaring either way. - **Pattern matching** (`instanceof SQLException sql`) is the clean modern way to recover subtype methods inside a broadened catch. ## Summary The multi-catch variable is typed as the alternatives' least upper bound (limiting callable methods to that supertype), while precise rethrow — enabled because the parameter is effectively/implicitly final — lets a `throw e;` propagate the *actual* narrow exception set. The design lets you consolidate handling without sacrificing the precision of your method's `throws` contract.