What is 'more-precise rethrow' analysis introduced in Java 7, and how does it let a method declare narrower checked exceptions than the catch type suggests?

## Background: checked exceptions and `throws` Java has **checked exceptions** — subclasses of `Exception` (excluding `RuntimeException`) that the compiler forces you to either catch or declare with a `throws` clause on the method. This is part of Java's type system: the set of checked exceptions a method may throw is part of its contract. ## The pre-Java-7 limitation Suppose you want one catch block to do shared cleanup or logging, then rethrow: ```java void run() throws ??? { try { mightThrowIOException(); // throws IOException mightThrowSQLException(); // throws SQLException } catch (Exception e) { log.error("failed", e); throw e; // rethrow } } ``` Before Java 7, the compiler looked only at the **declared type of the catch parameter** — here `Exception`. So `throw e;` was considered to throw `Exception`, and the method was forced to declare `throws Exception`. That is imprecise: it pollutes the method's contract, forcing every caller to handle `Exception` even though only `IOException` and `SQLException` can really occur. To get a precise contract you had to write two separate catch blocks (`catch (IOException e)`, `catch (SQLException e)`), duplicating the cleanup code. ## What Java 7 added: more-precise rethrow analysis Java 7 (Project Coin) made the compiler smarter. When you rethrow a caught exception, instead of using the *declared* type of the catch parameter, the compiler computes the **set of exception types that can actually propagate** from the `try` block to that catch, and treats the rethrow as throwing exactly that set. In the example, the only checked exceptions thrown in the `try` are `IOException` and `SQLException`. So the compiler treats `throw e;` as potentially throwing `IOException` *or* `SQLException` — and lets you write: ```java void run() throws IOException, SQLException { try { mightThrowIOException(); mightThrowSQLException(); } catch (Exception e) { log.error("failed", e); throw e; // analysed as IOException | SQLException } } ``` Callers now only need to handle those two precise types. You get the convenience of one broad catch *and* a precise contract. ## The critical condition: the catch parameter must be effectively final This precision only applies when you do **not reassign** the catch parameter inside the block. The parameter is then "effectively final." If you reassign it: ```java catch (Exception e) { e = new Exception("replaced"); // reassigned! throw e; // now treated as plain Exception } ``` the compiler can no longer prove which precise type `e` holds, so it falls back to the declared catch type (`Exception`) and you must declare `throws Exception` again. As a courtesy, Java 7 also lets you mark the parameter `final` explicitly to make the intent clear, but it is not required — "effectively final" suffices. ## How the analysis decides the type set The compiler unions: 1. The checked exception types thrown by statements in the `try` body that the catch can catch, **minus** any caught by earlier (more specific) catch clauses, and 2. narrowed to subtypes of the catch parameter's declared type. Unchecked exceptions (`RuntimeException`/`Error`) are not part of the `throws`-relevant set, so they don't appear in the declaration regardless. ## Why it matters - Lets you consolidate duplicated cleanup/logging into a single catch without widening your method's checked-exception contract. - Works hand-in-hand with **multi-catch** (`catch (IOException | SQLException e)`), another Java 7 feature; multi-catch parameters are *implicitly final* and also benefit from precise typing. - Keeps APIs honest: callers handle only the exceptions that can truly occur. ## Summary More-precise rethrow = the compiler infers the *actual* reachable checked-exception types at a `throw e;` of an effectively-final catch parameter, rather than using the broad declared catch type — so a broad catch can coexist with a narrow `throws`.