Code10x
Exceptionseasy0-2 years

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?

The caller catches the original business exception from the body — that's the one that propagates. The close() failure isn't lost, but it also isn't the exception the caller sees directly: it's attached to the body's exception as a suppressed exception, retrievable through getSuppressed() and printed in the stack trace under Suppressed:. This is exactly the problem the old manual finally { conn.close(); } pattern couldn't solve — there, if close() threw, it replaced the body's exception outright, and whoever was debugging saw "connection close failed" with no idea the real problem was a business rule violation three lines earlier. try-with-resources keeps the primary failure as primary and preserves the secondary one alongside it instead of discarding either.

The lesson behind it →
PreviousA 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?Next A 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?
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 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?