Java · OOP, JVM and backend craft
What is the difference between checked and unchecked exceptions?
Short answer
Checked exceptions must be caught or declared and represent recoverable conditions. Unchecked exceptions extend RuntimeException and usually signal programming errors or unrecoverable state.
The compiler enforces checked exceptions through the throws clause. IOException, SQLException and InterruptedException are checked. NullPointerException, IllegalArgumentException and IllegalStateException are unchecked because they usually indicate a bug rather than an expected environmental failure.
public String readFirstLine(Path path) throws IOException {
try (BufferedReader reader = Files.newBufferedReader(path)) {
return reader.readLine();
}
}Design trade-offs
- Checked exceptions force callers to acknowledge a recoverable failure
- They can clutter every layer and encourage catch-and-ignore
- Unchecked exceptions keep signatures clean but rely on documentation and validation
- Spring translates many data-access failures into unchecked DataAccessException subclasses
Use checked exceptions when the caller can plausibly recover, such as retrying a transient IO failure or asking for a different file. Use unchecked exceptions for invalid arguments and broken invariants. At an application boundary, translate infrastructure exceptions into a domain-specific unchecked exception with the original cause preserved.
Follow-ups you should expect
Interviewers use these to check whether the first answer was understanding or memorisation.
- 1When is a checked exception the right design?
- 2Why do many modern APIs prefer unchecked exceptions?
- 3What does Spring do with checked data-access exceptions?
- 4Why is catching Exception usually a smell?
Say it in the interview
Checked exceptions are enforced by the compiler and should represent conditions a caller can recover from, like a missing file or a transient network failure. Unchecked exceptions extend RuntimeException and usually signal a programming error or a broken invariant. I use checked exceptions sparingly because they spread through signatures, and I translate infrastructure failures at the boundary while preserving the cause.
Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.
Related questions
Reading is step one
Now say it out loud.
Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live Java mock interview and get scored feedback on depth, clarity and confidence.