Exception Handling
Checked vs Unchecked Exceptions
Conduct a comparative analysis of checked vs unchecked classifications, recoverability, and library designs.
Interview: Highly tested: Exception classification criteria (recoverable vs programming bug), standard checked/unchecked class roots, and framework design preferences.
Java categorizes exceptions into Checked and Unchecked exceptions. This distinction dictates whether the compiler enforces the handle-or-declare rule, representing different architectural approaches to error handling.
Checked Exceptions
Extend Exception but not RuntimeException. Enforced by compiler; represent recoverable runtime conditions.
Unchecked (Runtime)
Extend RuntimeException. Not checked by the compiler; represent programming errors or bugs.
Design Philosophy
Modern frameworks (e.g. Spring, Hibernate) use unchecked exceptions to keep method signatures clean and avoid boilerplate.
Comparison Analysis
The differences between checked and unchecked exceptions are structural and behavioral:
| Feature | Checked Exceptions | Unchecked Exceptions |
|---|---|---|
| Class Root | Exception (excluding RuntimeException subclasses). |
RuntimeException. |
| Compiler Checks | Yes. Checked at compile time (handle-or-declare). | No. Checked only at runtime. |
| Conceptual Nature | Recoverable, external failure states (e.g. IOException). |
Programming bugs or internal faults (e.g. NullPointerException). |
| Method Signatures | Requires explicit declaration in the throws clause. |
Does not require declaration in the method signature. |
Common Pitfalls
- Forcing Checked Exceptions for Bugs: Declaring checked exceptions for programming bugs (e.g., passing invalid array indexes), which forces unnecessary try-catch boilerplate onto callers.
- Catching RuntimeException indiscriminately: Catching
RuntimeExceptionglobally to prevent crashes, which can hide bugs (like null pointers or divide-by-zero errors) instead of fixing them.
Best Practices
- Use Checked for Recoverable Conditions: Use checked exceptions only if the caller can programmatically recover from the error (e.g., prompting the user for a new filename if the file is missing).
- Use Unchecked for Programming Errors: Use unchecked exceptions for API contract violations (e.g. invalid arguments, null references) or unrecoverable system failures.
Interview-Relevant Information
Q1: Contrast checked and unchecked exceptions.
Answer: Checked exceptions (subclasses of Exception excluding RuntimeException) are checked by the compiler. Callers must handle or declare them. They represent recoverable failures. Unchecked exceptions (subclasses of RuntimeException) are not checked at compile time and represent programming bugs or unrecoverable failures.
Q2: Why do modern Java frameworks like Spring prefer unchecked exceptions?
Answer: To reduce boilerplate and signature clutter. Checked exceptions force callers to write try-catch blocks or declare throws clauses even when they cannot recover from the error. Spring wraps these in unchecked exceptions (e.g., DataAccessException), allowing clean code while delegating error handling to global controller boundaries.
Quick Checklist
Can you distinguish checked from unchecked exceptions, explain the compiler's handle-or-declare enforcement, and list the design guidelines for choosing between them? If yes, you understand checked vs unchecked exceptions.
Use Cases
Declaring expected user recovery scenarios (e.g. invalid login password).
Throwing runtime assertions when internal API structures are violated.
Common Mistakes
Marking programming bugs as checked exceptions, forcing callers to write redundant catch blocks.
Wrapping all framework logic in checked exceptions and propagating throws clauses up to the main method.