ReviseAlgo Logo

Exception Handling

Exception Hierarchy

Map the Throwable class hierarchy structure, separate Errors from Exceptions, and map JVM errors.

Interview: Evaluates the java.lang.Throwable tree layout, distinguishing Error from Exception, and positioning of RuntimeException.

Last Updated: June 13, 2026 • 10 min read

The Java exception system is structured as a class hierarchy rooted at the Throwable class. Mapping this hierarchy is key to understanding compiler checks and JVM runtime behaviors.

Throwable Root

The root class of all exceptions and errors. Only objects inheriting from Throwable can be thrown or caught.

Error vs. Exception

Errors represent unrecoverable system failures. Exceptions represent recoverable application conditions.

RuntimeException

A specific subclass of Exception that acts as the root class for all unchecked runtime exceptions.

The Throwable Class Hierarchy Tree

The exception class tree is structured as follows: 


                  [java.lang.Object]
                           |
                 [java.lang.Throwable]
                  /                          [java.lang.Error]     [java.lang.Exception]
          (System Failures)     (Application Errors)
          e.g. OutOfMemoryError         /                  e.g. StackOverflowError  [RuntimeException]  [Checked Exceptions]
                                  (Unchecked/Bugs)    e.g. IOException
                               e.g. NullPointerException  e.g. SQLException

Common Pitfalls

  • Catching Throwable: Catching Throwable instead of Exception, which intercepts fatal system errors (like OutOfMemoryError) and prevents the JVM from shutting down safely.
  • Assuming all Exceptions are Checked: Forgetting that RuntimeException extends Exception, meaning that while all runtime exceptions inherit from Exception, they are unchecked.

Best Practices

  • Catch Specific Exception Types: Always catch the most specific exception class possible (e.g. FileNotFoundException rather than a generic Exception).
  • Do Not Intercept Errors: Never write catch blocks targeting Error or its subclasses. If a fatal JVM error occurs, let the process terminate.

Interview-Relevant Information

Q1: What is the hierarchy parent of RuntimeException? Is it checked or unchecked?
Answer: RuntimeException inherits from Exception. However, it is unchecked. Any exception class that extends RuntimeException is checked only at runtime, bypassing compile-time handle-or-declare requirements.

Q2: Why should we avoid catching java.lang.Error?
Answer: Classes inheriting from Error represent severe, unrecoverable system conditions (such as OutOfMemoryError or StackOverflowError). Intercepting them can keep the application running in an unstable state, risking data corruption.

Quick Checklist

Can you draw the Throwable inheritance tree, distinguish Exception from Error, and explain where RuntimeException fits in the hierarchy? If yes, you understand the exception hierarchy.

Use Cases

Configuring global JVM uncaught exception handlers for logging unhandled errors.

Analyzing stack traces to determine if errors represent recoverable application states or fatal JVM conditions.

Common Mistakes

Intercepting Throwable inside web service controllers, which catches and hides JVM errors.

Assuming all subclasses of Exception are checked exceptions.