Code10x
Exceptionshard5-8 years

A colleague shows you code that throws a checked `IOException` straight out of a `Runnable.run()` — no wrapping, no `UncheckedIOException` — and it compiles cleanly with no error anywhere. How is that possible, and what does it prove about what "checked" actually means?

It's possible because checked-exception enforcement is entirely javac's doing — the JVM itself has no concept of "checked" at all. The athrow bytecode instruction that actually throws an exception is the same single instruction for every exception, checked or not; there's no flag on it that says "this one needed a throws clause." The trick (the "sneaky throws" technique Lombok's @SneakyThrows is built on) exploits generics erasure: a helper method declares throws T where T is an unconstrained type parameter, and at a call site with nothing pinning T down, javac infers it as RuntimeException — so the method looks, to the compiler, like it throws nothing checked. At run time, erasure has already happened, the cast inside the method is a no-op, and whatever Throwable was actually passed in goes out through the same athrow as anything else — including a genuine checked IOException, flowing straight through a Runnable.run() whose signature the compiler was certain could never see one.

The lesson behind it →
PreviousA service throws a single `ServiceException` for everything — not found, validation failure, and a downstream timeout all end up as the same type with different messages. What's wrong with that design, and how would you restructure the hierarchy?Next A file-deletion call using `java.io.File` returns `false`, and the log just says "could not delete." A teammate wants to know why the delete failed — permission denied, the file was already gone, or something else. Why can't `File` tell you, and what changes with `java.nio.file.Files`?
More on Exceptions
A teammate declares `throws IOException` on a method three layers above where the exception is actually thrown, and every intermediate caller does the same because "that's what the compiler wants." What's actually wrong with reflexively propagating checked exceptions, and what rule should decide checked versus unchecked instead?A method opens a database connection in a `try-with-resources` block. The body throws a business exception, and `close()` on the connection also throws (the pool rejects a broken connection). What does the caller actually catch, and where did the `close()` failure go?