Checked vs Unchecked Exceptions

JavaEntryjava

The Question

What is the difference between checked and unchecked exceptions in Java?

What a Strong Answer Covers

• checked = compile-time verification
• must handle or declare with throws
• unchecked = runtime exceptions
• extend RuntimeException
• NullPointerException
• IOException examples

Senior-Level Answer

In Java, exceptions are divided into checked and unchecked. The distinction determines whether the compiler forces calling code to handle or declare the exception.

Checked exceptions are subclasses of Exception but not RuntimeException. The compiler enforces that any method which might throw a checked exception must either catch it or declare it with throws. Examples: IOException, SQLException, FileNotFoundException. These represent recoverable conditions — a file that does not exist, a dropped network connection.

Unchecked exceptions are subclasses of RuntimeException. The compiler does not require you to catch or declare them. Examples: NullPointerException, ArrayIndexOutOfBoundsException, IllegalArgumentException. These typically represent programming errors.

Errors (subclasses of Error, like OutOfMemoryError) are also unchecked but represent unrecoverable JVM-level problems.

The class hierarchy: Throwable is the root. It has two subclasses: Exception and Error. Under Exception, RuntimeException and its subclasses are unchecked. Everything else under Exception is checked.

The design rationale for checked exceptions is to force developers to consider failure modes. A method signature like void readFile(String path) throws IOException documents exactly what can go wrong.

However, checked exceptions are controversial. Critics argue they lead to boilerplate (empty catch blocks), poor abstraction (implementation details leaking into signatures), and scaling problems in large codebases. This is why Kotlin, Scala, and Spring predominantly use unchecked exceptions.

Best practices: use checked exceptions for recoverable conditions where the caller can take meaningful action. Use unchecked for programming errors and violated preconditions. Never swallow exceptions silently. When wrapping, preserve the original cause.

Key Differences

What Separates a 2/3 from a 3/3

Common Mistakes

• Saying unchecked exceptions 'cannot be caught' — they can, the compiler just does not require it
• Forgetting that Error is also unchecked but distinct from RuntimeException
• Not knowing the class hierarchy
• Failing to mention the controversy around checked exceptions
• Confusing Java's checked exception model with other languages

Follow-Up Questions

• Why did Kotlin eliminate checked exceptions? — Research showed developers overwhelmingly ignored them; they added noise without improving reliability.
• When would you convert a checked exception to unchecked? — When the caller cannot meaningfully recover — e.g., wrapping a config parse error at startup.
• What is the difference between throw and throws? — throw actually throws an exception object; throws is a method signature declaration.
• How does try-with-resources relate to checked exceptions? — AutoCloseable's close() throws Exception (checked); try-with-resources ensures cleanup.
• What is exception chaining? — Passing the original exception as the cause when wrapping — preserves the full stack trace.

Related Questions

• JVM vs JRE vs JDK
• Java Platform Independence
• How JVM Works
• Main Features of Java
• public static void main