Checked vs Unchecked Exceptions in Java — Hierarchy, Compiler Rules, and Modern Design Guidance

Q: Checked vs Unchecked Exceptions in Java — Hierarchy, Compiler Rules, and Modern Design Guidance

**Checked exceptions** are subclasses of `Exception` (not `RuntimeException`) — the compiler **forces** callers to catch or declare them (`throws`). Examples: `IOException`, `SQLException`. **Unchecked exceptions** are subclasses of `RuntimeException` — no compiler enforcement. Examples: `NullPointerException`, `IllegalArgumentException`. Design rule: **checked** when the caller has a **distinct recovery path** (retry, fallback); **unchecked** for programming errors or when callers have no meaningful response. Modern frameworks (Spring, JPA, Hibernate) wrap checked `SQLException` into unchecked `DataAccessException` because most callers can't recover and `throws` clauses pollute the API.

Intermediate·2 min read·

AmazonGoogleMicrosoftOracleNetflix

Fast recall

Quick revision

Core answer

Checked exceptions are subclasses of Exception (not RuntimeException) — the compiler forces callers to catch or declare them (throws). Examples: IOException, SQLException. Unchecked exceptions are subclasses of RuntimeException — no compiler enforcement. Examples: NullPointerException, IllegalArgumentException. Design rule: checked when the caller has a distinct recovery path (retry, fallback); unchecked for programming errors or when callers have no meaningful response. Modern frameworks (Spring, JPA, Hibernate) wrap checked SQLException into unchecked DataAccessException because most callers can't recover and throws clauses pollute the API.

Interview-ready guide

Interview answer

The split is about recoverability, not severity. Checked exceptions are the ones the compiler forces callers to acknowledge, because the designer thought callers would have a distinct recovery strategy.

Checked exceptions

Direct subclasses of Exception (not RuntimeException): IOException, SQLException, ParseException, InterruptedException
Compiler forces catch-or-declare — every caller must either handle them or add them to their own throws clause
Represent recoverable external conditions: file not found, network timeout, malformed input

Unchecked exceptions

Subclasses of RuntimeException: NullPointerException, IllegalArgumentException, ClassCastException
No compiler enforcement; represent programming bugs
The right response is to fix the code, not catch and hide the bug

Errors

OutOfMemoryError, StackOverflowError — JVM-level failures; almost never catch them

Why the industry shifted toward unchecked

throws clauses metastasize across wide APIs — every method that might touch a database ends up with throws SQLException
Streams and lambdas don't accept checked exceptions cleanly — Function can't throw IOException
Spring wraps SQLException into DataAccessException (unchecked) so service code stays clean
Kotlin and Scala dropped checked exceptions entirely

Recommendation: In a modern REST service, default to unchecked custom exceptions (with preserved causes) plus a @ControllerAdvice global handler that maps them to structured HTTP responses. Reserve checked for narrow libraries where callers truly have distinct recovery paths, and always restore the interrupt flag on InterruptedException if you don't rethrow.

03 · Deep dive