Checked vs Unchecked Custom Exception Decision
Fast recall
Quick revision
Core answer
Whether you can decide checked vs unchecked based on recoverability and modern practice, not just textbook rules
Defaulting to checked exceptions everywhere, creating throws clutter the caller can't usefully act on
State the modern default is unchecked, justified by composability and Spring's DataAccessException precedent
Interview-ready guide
Interview answer
I choose a checked custom exception when requiring every direct caller to acknowledge a named failure makes the API safer. I choose an unchecked custom exception when that declaration would mainly be passed through layers or callbacks that cannot act on it. The decision is an API design choice, not a rule that checked always means recoverable and unchecked always means a bug.
For example, a reusable file-import library might declare InvalidImportFormatException if its callers are expected to ask for another file. A Spring service might throw an unchecked CustomerNotFoundException, which an HTTP exception handler maps to 404 at the application boundary. In both cases I give the type a clear meaning, document when it occurs, and preserve the original cause when translating a lower-level failure. I do not create a new type merely to rename a generic message.
Checked vs Unchecked Custom Exception Decision
Direct Answer
Choose a checked custom exception when the API deliberately requires every direct caller to catch or declare a named failure. Choose unchecked when forcing that declaration would not help callers, such as many invariant, validation, or boundary-translated application failures. Recoverability alone is not a reliable test; consider the abstraction, caller actions, callback ecosystem, and compatibility of the public API.
Common Mistakes & Pitfalls
- Defaulting to
checkedeverywhere — every layer grows athrowsclause the caller can't act on. - Making validation failures
checked— bad input is a bug to fix, soRuntimeExceptionfits better. - Using
checkedinside lambdas/streams — it won't compile; the functional interfaces don't declare it. - Flipping
checkedto unchecked late — it silently drops the compiler's forced-handling from existing callers.
Check your understanding
Answer these without looking back at the article.
- What is @ControllerAdvice and how does it handle unchecked exceptions globally?
- Can you convert a checked custom exception to unchecked later without breaking clients?
- How does Hibernate decide which exceptions to make checked vs unchecked?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.