How can a method rethrow a checked exception without declaring it in its throws clause, and why is the 'sneaky throws' technique controversial?

## Recap: checked vs unchecked, and where the rule lives Java splits throwables into **checked** (subclasses of `Exception` except `RuntimeException`) and **unchecked** (`RuntimeException`, `Error`, and their subclasses). The rule 'a method must declare or catch its checked exceptions' is enforced **only by the compiler** (`javac`). The **JVM has no such concept** — at the bytecode level, throwing and catching work identically for any `Throwable`. This gap is what sneaky throws abuses. ## The classic sneaky-throws trick ```java @SuppressWarnings("unchecked") static <E extends Throwable> void sneakyThrow(Throwable e) throws E { throw (E) e; // unchecked cast; E is inferred and erased } ``` Why does this compile and run? - `E` is a type variable. At the call site the compiler infers `E` as `RuntimeException` (the inference default), so `throws E` looks like `throws RuntimeException` — an *unchecked* declaration, which callers need not handle. - Because of **type erasure**, the cast `(E) e` generates no real runtime check. So a checked exception object passes through unharmed. - At runtime the *actual* object (say an `IOException`) is thrown. The JVM doesn't care that no signature declared it. Usage: ```java void run() { // note: no throws clause! try { readFile(); // declares throws IOException } catch (IOException e) { sneakyThrow(e); // rethrows the checked IOException, undeclared } } ``` `run()` throws an `IOException` at runtime while declaring nothing. Lombok's `@SneakyThrows` generates essentially this. ## How this relates to legitimate rethrow Normal, correct rethrow (`throw e;`) and more-precise rethrow keep the **contract honest** — the checked types still appear in `throws`. Sneaky throws does the opposite: it *hides* the checked type from the contract. So it's the dark mirror of the rethrow topic: same runtime mechanism (propagating the same instance preserves the trace), but it deliberately subverts the static guarantee. ## Why it's controversial 1. **Broken contract / invisible failure modes.** Callers reading `void run()` have no signal that an `IOException` can emerge. They can't be *forced* to handle it, and they can't write `catch (IOException e)` confidently because the compiler may complain that `IOException` is never thrown in the try (depending on context) — you sometimes must catch the broad `Exception` or use `instanceof`. 2. **Surprises maintainers and tooling.** Static analysers, IDE 'add throws' quick-fixes, and code generators assume signatures are truthful. Sneaky throws makes signatures lie. 3. **Harder exception translation.** Layered architectures translate low-level checked exceptions into domain ones at boundaries; sneaky throws lets a raw checked exception leak across layers it should never reach. 4. **Debugging confusion.** A stack trace shows a checked exception thrown from a method whose signature says it can't — confusing to readers who trust signatures. ## When (if ever) it's defensible - **Bridging checked exceptions through functional interfaces.** `java.util.function` types (`Function`, `Supplier`, etc.) don't declare checked exceptions, so a lambda that calls a throwing method won't compile. Sneaky throws (often via a small wrapper utility or Lombok) lets the checked exception flow through the stream pipeline. Many teams instead prefer wrapping in an unchecked exception (`UncheckedIOException`) for honesty, but sneaky throws preserves the original type without a wrapper. - **Framework/codegen internals** where the surrounding code controls all callers and documents the behaviour. Even then, the wrap-in-unchecked approach (`throw new UncheckedIOException(e)`) is usually clearer: it advertises *un*checked propagation, keeps the original as the cause, and doesn't lie about checkedness. ## Principal-level perspective The deeper lesson is that **checked exceptions are a compile-time fiction the JVM doesn't enforce**, so any guarantee they provide is only as strong as the team's discipline and tooling. Whether to allow sneaky throws is a *policy* decision: it can reduce boilerplate in lambda-heavy code but erodes the readability and the 'honest signature' invariant that large codebases rely on. Most teams ban it outside narrow, well-documented adapter utilities. ## Summary Sneaky throws rethrows a checked exception without declaring it by exploiting generics inference + erasure, relying on the fact that the JVM ignores checkedness. It runs fine but breaks the contract checked exceptions exist to express — hence the controversy.