Exception Hierarchy in Java: Checked, Unchecked, and Errors

Introduction

Understanding the Exception Hierarchy in Java is vital for writing reliable and maintainable code. Exceptions in Java are represented through a structured class hierarchy, rooted in the Throwable class. This hierarchy helps developers categorize and handle different error conditions efficiently, whether they are recoverable or not.

1. Root of the Hierarchy: Throwable

At the top of the Exception Hierarchy is the Throwable class. It has two direct subclasses:

• Error: Represents serious problems that applications should not try to catch.
• Exception: Indicates conditions that a program might want to catch.

Throwable
 ├── Error
 └── Exception

“To handle exceptions effectively, you must first understand where they come from.”

2. Errors in Java

The Error class and its subclasses represent critical conditions, such as OutOfMemoryError or StackOverflowError, that are not meant to be caught by applications.

try {
    // Simulate error (not recommended in practice)
    throw new StackOverflowError("Critical Error");
} catch (Error e) {
    System.out.println("Caught an Error: " + e);
}

In most real-world scenarios, developers log these and allow them to propagate.

3. Checked Exceptions

Checked exceptions are subclasses of Exception (but not RuntimeException). They must be either caught or declared using the throws keyword.

Examples include:

• IOException
• SQLException

try {
    throw new java.io.IOException("File not found");
} catch (java.io.IOException e) {
    System.out.println("Handled checked exception: " + e.getMessage());
}

Checked exceptions encourage explicit error handling and are checked at compile-time.

4. Unchecked Exceptions

Unchecked exceptions extend the RuntimeException class.

These include:

• NullPointerException
• ArrayIndexOutOfBoundsException
• IllegalArgumentException

You don’t need to declare or catch them, but you should still handle them when possible.

try {
    String s = null;
    s.length(); // Throws NullPointerException
} catch (NullPointerException e) {
    System.out.println("Caught unchecked exception: " + e.getMessage());
}

“Unchecked exceptions don’t require you to catch them, but professional code often does.”

5. Custom Exceptions

Developers can define their own exception classes by extending Exception or RuntimeException. This enables application-specific error reporting.

class CustomException extends Exception {
    public CustomException(String message) {
        super(message);
    }
}

Custom exceptions improve clarity and allow better abstraction for domain-specific problems.

6. Summary of Exception Hierarchy

Here’s a summarized view of the Exception Hierarchy:

Throwable
 ├── Error
 │   └── OutOfMemoryError, StackOverflowError, etc.
 └── Exception
     ├── IOException, SQLException, etc. (Checked)
     └── RuntimeException
         ├── NullPointerException, IndexOutOfBoundsException, etc. (Unchecked)

Understanding this structure is critical when designing exception handling strategies. For deeper insights into practical handling, see our article on Handling exceptions in Java.

Conclusion

The Exception Hierarchy in Java provides a systematic way to represent and manage errors. Differentiating between errors, checked, and unchecked exceptions empowers developers to write robust and readable code. By mastering this hierarchy, developers can improve both the quality and clarity of their exception handling practices.

You can find the complete code of this article on GitHub.