Java Exception Hierarchy – Throwable, Exception, and Error

Java provides a robust and predictable error-handling system, and at the heart of this system lies the exception hierarchy rooted in the Throwable class.

Understanding this hierarchy gives you several advantages:

• Write cleaner and safer code
• Respond appropriately and recover from errors
• Easier debugging and maintenance
• Build more reliable programs

In this article, we’ll visualize the Java exception hierarchy, explain each layer, and cover practical exception handling strategies and best practices you’ll use every day.

Java Exception Hierarchy at a Glance

1. Top-Level Class: Throwable

At the very top is the Throwable class, which represents anything that can be thrown as an error or exception.
It has two main direct subclasses:

• Error: Serious problems at the JVM or system level (not recoverable)
• Exception: Application-level issues (recoverable)

2. Error – System/JVM-Level Critical Failures

Error represents severe problems that applications should not try to handle—these are typically related to the JVM or hardware.

Class	Description
StackOverflowError	Thrown when the stack overflows (e.g., infinite recursion)
OutOfMemoryError	Thrown when the JVM runs out of memory
VirtualMachineError	Indicates internal JVM errors (e.g., JIT failures)

Tip: Never try to catch or handle Error in your code—let the JVM take care of it.

3. Exception – Recoverable Application-Level Issues

Exception covers problems that can occur during normal program execution and that your application might want to catch and recover from.

Common Subclasses

Class	Description
IOException	I/O issues (e.g., file not found, network problems)
SQLException	Problems encountered during database access
ClassNotFoundException	Thrown when a class can’t be found at runtime
RuntimeException	Unchecked exceptions, usually programming mistakes

4. Checked vs Unchecked Exceptions

Checked Exceptions

• Compiler enforces handling
• Must be declared with throws or handled with try-catch
• Typically caused by external factors (files, network, database)

try {
    BufferedReader reader = new BufferedReader(new FileReader("file.txt"));
} catch (IOException e) {
    System.out.println("Unable to read the file.");
}

Unchecked Exceptions (RuntimeException)

• Compiler does not require handling
• Usually caused by programming errors (bugs)
• Examples: invalid index, null access, bad parsing

int[] arr = {1, 2, 3};
System.out.println(arr[5]); // ArrayIndexOutOfBoundsException

5. Key Subclasses of RuntimeException

Exception Class	Description
ArithmeticException	Arithmetic errors (e.g., division by zero)
NullPointerException	Accessing a method or field on null
NumberFormatException	Failing to parse a string as a number
IndexOutOfBoundsException	Accessing an array/list index out of bounds

IndexOutOfBoundsException has important subclasses:

• ArrayIndexOutOfBoundsException
• StringIndexOutOfBoundsException

6. Creating Custom Exceptions

You can define your own exceptions to fit your business logic.

// Example of a checked exception
public class InsufficientBalanceException extends Exception {
    public InsufficientBalanceException(String message) {
        super(message);
    }
}

// Example of an unchecked exception
public class InvalidUserInputException extends RuntimeException {
    public InvalidUserInputException(String message) {
        super(message);
    }
}

Usage example:

void withdraw(int amount) throws InsufficientBalanceException {
    if (balance < amount) {
        throw new InsufficientBalanceException("Insufficient balance!");
    }
}

7. Real-World Exception Handling Best Practices

1. When should you use checked exceptions?

• When working with external resources (files, network, databases)
• When you want to force the caller to handle potential failures

2. When should you use unchecked exceptions?

• For clear programming mistakes (contract violations, invalid arguments)
• When you don’t want to force the caller to handle the exception

3. Never catch Error!

• System/JVM-level errors should always be left to the JVM.

4. Write specific, meaningful exception messages!

• Exception messages should help pinpoint the cause and possible solution.

5. Use exception chaining and wrapping

• Wrapping exceptions with the original cause makes debugging easier.

try {
    // ...
} catch (IOException e) {
    throw new CustomAppException("Error processing file", e);
}

6. Use try-with-resources for automatic resource management

try (BufferedReader br = new BufferedReader(new FileReader("test.txt"))) {
    // Read file
} catch (IOException e) {
    // Handle exception
}

7. Avoid unnecessary catch-all blocks!

• Catch only specific exceptions, and log or rethrow unexpected ones.

8. Common Mistakes & Patterns to Avoid

• Catching all exceptions and ignoring them
• Failing to log exceptions or provide context
• Converting checked exceptions to unchecked without good reason
• Overwriting exceptions in the finally block