← Back to Home

Checked vs Unchecked Exceptions

Java classifies exceptions into Checked and Unchecked to enforce compile-time safety where appropriate and allow runtime flexibility where necessary. Understanding this distinction is critical for API design, robust code, and interviews.

What Are Checked Exceptions?

Checked exceptions are exceptions that are checked by the compiler at compile time.

Key Characteristics

  • Checked at compile time
  • Must be handled using try-catch or declared using throws
  • Represent recoverable conditions
  • Usually related to external systems (I/O, DB, network)

Examples

  • IOException
  • SQLException
  • ClassNotFoundException
  • FileNotFoundException

Example

void readFile() throws IOException {
    FileReader fr = new FileReader("data.txt");
}
❌ Compile-time error if not handled or declared
✔ Forces developer to think about recovery
          

What Are Unchecked Exceptions?

Unchecked exceptions are not checked by the compiler and occur at runtime.

Key Characteristics

  • Occur at runtime
  • Compiler does not force handling
  • Usually caused by programming errors
  • Extend RuntimeException

Examples

  • NullPointerException
  • ArithmeticException
  • ArrayIndexOutOfBoundsException
  • NumberFormatException

Example

int a = 10 / 0; // ArithmeticException
✔ Compiles successfully
❌ Fails at runtime
          

Exception Hierarchy (Important)

Throwable
 ├── Exception
 │    ├── Checked Exceptions (IOException, SQLException)
 │    └── RuntimeException (Unchecked)
 │         ├── NullPointerException
 │         ├── ArithmeticException
 │         └── IndexOutOfBoundsException
 └── Error
          

Core Differences: Checked vs Unchecked (Interview Favorite)

Aspect Checked Exceptions Unchecked Exceptions
Compiler check ✅ Yes ❌ No
When detected Compile time Runtime
Must handle ✅ Yes ❌ No
Parent class Exception RuntimeException
Cause External / Recoverable Programming bugs
API usage Mandatory handling Optional handling

Handling Requirements

Checked Exception — Mandatory

try {
    FileReader fr = new FileReader("file.txt");
} catch (IOException e) {
    e.printStackTrace();
}
OR

void method() throws IOException { }
          

Unchecked Exception — Optional

int[] arr = new int[3];
System.out.println(arr[5]); // Runtime failure
✔ No compiler enforcement
✔ Better prevented using validations
          

Why Java Introduced Checked Exceptions

  • Forces robust error handling
  • Prevents silent failures
  • Improves reliability of enterprise applications
  • Encourages explicit recovery logic

Why Unchecked Exceptions Exist

  • Avoid cluttering code with excessive try-catch
  • Represent coding mistakes
  • Improve code readability
  • Fail fast during development

Best Practices (Real-World)

Use Checked Exceptions When:

  • Error is recoverable
  • Caller can take corrective action
  • Dealing with external resources

Use Unchecked Exceptions When:

  • Error indicates programming bug
  • Recovery is not meaningful
  • Precondition violations occur

Common Beginner Mistakes

  • Catching Exception everywhere
  • Ignoring checked exceptions using empty catch blocks
  • Converting all exceptions to unchecked
  • Using checked exceptions for programming errors

Interview-Ready Answers

Short Answer

Checked exceptions are verified by the compiler and must be handled, while unchecked exceptions occur at runtime and are not enforced by the compiler.

Detailed Answer

In Java, checked exceptions represent recoverable conditions and must be either handled or declared at compile time. Unchecked exceptions extend RuntimeException and usually indicate programming errors. Java uses this distinction to balance safety and flexibility.

Key Takeaway

Checked exceptions enforce responsibility. Unchecked exceptions enforce correctness. Using the right exception type leads to cleaner APIs, safer code, and better maintainability.