The Java exception hierarchy is a class tree rooted at java.lang.Throwable. Every object that can be thrown — whether it is a null pointer dereference, a missing file, or a heap exhaustion — is an instance of some class in this tree. The position of an exception class in that tree determines three things: whether the compiler forces you to handle it, which catch block intercepts it, and what it signals about the severity of the problem. Knowing the hierarchy is not just academic preparation — it explains every catch block ordering rule, every compiler error about unhandled exceptions, and every design decision behind custom exception classes.

What Is the Java Exception Hierarchy?

The hierarchy begins with java.lang.Throwable. Everything below it inherits the core state that makes exceptions useful: a human-readable message, a reference to the exception that caused this one, and the stack trace captured at the moment the exception was created.

java.lang.Object
    └── java.lang.Throwable
            ├── message     : String   (what went wrong)
            ├── cause       : Throwable (what triggered this — exception chaining)
            ├── stackTrace  : StackTraceElement[] (call chain at creation time)
            └── suppressed  : Throwable[] (exceptions suppressed by try-with-resources)

KEY METHODS ON Throwable:
  getMessage()          returns the message string
  getCause()            returns the causing Throwable (or null)
  getStackTrace()       returns the stack trace array
  printStackTrace()     prints the full chain to stderr
  getSuppressed()       returns suppressed exceptions from try-with-resources
  initCause(Throwable)  sets the cause after construction (older pattern)

Throwable has two direct subclasses:

  java.lang.Error               java.lang.Exception
  JVM and system failures       Application-level failures
  Almost never catch            Always handle with a strategy

The full tree below shows where every commonly encountered type sits.

java.lang.Throwable
    |
    +── java.lang.Error                        JVM-LEVEL (do NOT catch)
    |       ├── VirtualMachineError
    |       │     ├── OutOfMemoryError
    |       │     └── StackOverflowError
    |       ├── LinkageError
    |       │     ├── NoClassDefFoundError
    |       │     └── ExceptionInInitializerError
    |       ├── ThreadDeath
    |       └── AssertionError
    |
    +── java.lang.Exception                    APPLICATION-LEVEL
            |
            +── java.lang.RuntimeException     UNCHECKED — compiler does NOT enforce
            |       ├── NullPointerException
            |       ├── IllegalArgumentException
            |       │     └── NumberFormatException
            |       ├── IllegalStateException
            |       ├── IndexOutOfBoundsException
            |       │     ├── ArrayIndexOutOfBoundsException
            |       │     └── StringIndexOutOfBoundsException
            |       ├── ClassCastException
            |       ├── ArithmeticException
            |       ├── UnsupportedOperationException
            |       └── ConcurrentModificationException
            |
            +── java.io.IOException            CHECKED — compiler enforces handling
            |       ├── FileNotFoundException
            |       └── SocketException
            |
            +── java.sql.SQLException          CHECKED
            +── java.lang.ClassNotFoundException   CHECKED
            +── java.lang.CloneNotSupportedException CHECKED
            +── java.lang.InterruptedException     CHECKED
            +── java.lang.ReflectiveOperationException CHECKED
                    └── NoSuchMethodException

Basic Overview — What Position in the Hierarchy Controls

WHERE A CLASS SITS IN THE HIERARCHY DETERMINES:

  1. WHETHER THE COMPILER ENFORCES HANDLING:
     Subclass of RuntimeException OR Error → unchecked → no compile error if not caught
     Subclass of Exception (not RuntimeException) → checked → must catch or declare throws

  2. WHICH CATCH BLOCK MATCHES:
     Java uses instanceof to match exceptions to catch blocks.
     catch(IOException e) catches IOException AND all its subclasses.
     catch(Exception e) catches EVERYTHING below Exception.
     catch(Throwable t) catches absolutely everything — almost never do this.

  3. CATCH BLOCK ORDER RULE:
     More specific (deeper in tree) MUST appear before more general.
     FileNotFoundException before IOException — FileNotFoundException IS-A IOException.
     IOException before Exception.
     If you put IOException after Exception, the compiler rejects the code
     as "exception IOException has already been caught".

  4. WHAT IT SIGNALS TO CALLERS:
     Checked exception in throws clause = "this failure is expected, handle it"
     Unchecked exception thrown = "this is a programming mistake, fix it"
     Error = "the JVM is in trouble, nothing you can do"

  5. HOW EXCEPTION CHAINING WORKS:
     Every Throwable can hold a cause reference (another Throwable).
     new ServiceException("payment failed", originalSQLException)
     Calling getCause() on the ServiceException returns the SQLExcption.
     printStackTrace() shows the full chain — root cause last.

The Throwable Foundation

Every exception carries four pieces of state inherited from Throwable. Understanding these explains what you see in production logs and how to design useful custom exceptions.

Java

Try it out

// File: ThrowableStateDemo.java

public class ThrowableStateDemo {

    public static void main(String[] args) {

        // Constructing and inspecting Throwable state
        RuntimeException rootCause = new RuntimeException("Database connection refused");
        IllegalStateException wrapper = new IllegalStateException(
            "Service unavailable — downstream DB failed", rootCause);

        System.out.println("=== Throwable state fields ===");
        System.out.println("getMessage()       : " + wrapper.getMessage());
        System.out.println("getCause()         : " + wrapper.getCause());
        System.out.println("getCause().getMessage(): " + wrapper.getCause().getMessage());

        System.out.println();

        // Stack trace elements
        System.out.println("=== Stack trace elements (top 3) ===");
        StackTraceElement[] trace = wrapper.getStackTrace();
        for (int i = 0; i < Math.min(3, trace.length); i++) {
            System.out.println("  [" + i + "] " + trace[i]);
        }

        System.out.println();

        // Exception chaining — following the cause chain manually
        System.out.println("=== Exception cause chain ===");
        Throwable current = wrapper;
        int level = 0;
        while (current != null) {
            System.out.printf("  Level %d: %s — %s%n",
                level++,
                current.getClass().getSimpleName(),
                current.getMessage());
            current = current.getCause();
        }

        System.out.println();

        // instanceof — the mechanism behind catch block matching
        System.out.println("=== instanceof relationships (how catch matching works) ===");
        IOException ioException = new FileNotFoundException("config.yml not found");

        System.out.println("FileNotFoundException instanceof FileNotFoundException : " +
            (ioException instanceof FileNotFoundException));
        System.out.println("FileNotFoundException instanceof IOException           : " +
            (ioException instanceof IOException));
        System.out.println("FileNotFoundException instanceof Exception             : " +
            (ioException instanceof Exception));
        System.out.println("FileNotFoundException instanceof Throwable            : " +
            (ioException instanceof Throwable));
        System.out.println("FileNotFoundException instanceof RuntimeException     : " +
            (ioException instanceof RuntimeException));
    }
}

Output:
=== Throwable state fields ===
getMessage()       : Service unavailable — downstream DB failed
getCause()         : java.lang.RuntimeException: Database connection refused
getCause().getMessage(): Database connection refused

=== Stack trace elements (top 3) ===
  [0] ThrowableStateDemo.main(ThrowableStateDemo.java:8)
  [1] ...
  [2] ...

=== Exception cause chain ===
  Level 0: IllegalStateException — Service unavailable — downstream DB failed
  Level 1: RuntimeException — Database connection refused

=== instanceof relationships (how catch matching works) ===
FileNotFoundException instanceof FileNotFoundException : true
FileNotFoundException instanceof IOException           : true
FileNotFoundException instanceof Exception             : true
FileNotFoundException instanceof Throwable            : true
FileNotFoundException instanceof RuntimeException     : false

Checked Exceptions in the Hierarchy

Checked exceptions sit directly under Exception — not under RuntimeException. The compiler uses this position to enforce that callers either handle them or declare them. This position signals a design contract: these are failures that occur in normal operation and that calling code is expected to have a response for.

Java

Try it out

// File: CheckedHierarchyDemo.java

import java.io.FileNotFoundException;
import java.io.IOException;
import java.sql.SQLException;

public class CheckedHierarchyDemo {

    // The hierarchy determines what each catch block intercepts:
    // FileNotFoundException is caught by both catch(FileNotFoundException)
    // AND catch(IOException) — because FileNotFoundException extends IOException
    static void demonstrateCatchWidening(String path) {
        try {
            if (path.endsWith(".missing")) {
                throw new FileNotFoundException("File not found: " + path);
            }
            throw new IOException("Generic I/O failure on: " + path);
        } catch (FileNotFoundException fnfe) {
            // Catches only FileNotFoundException (and any subclasses it has)
            System.out.println("Specific handler — file missing: " + fnfe.getMessage());
        } catch (IOException ioe) {
            // Catches all remaining IOException subclasses not already caught above
            System.out.println("General I/O handler: " + ioe.getMessage());
        }
    }

    // Checked exceptions require throws declaration if not caught here
    static String loadConfig(String key) throws IOException, SQLException {
        if (key == null) throw new IOException("Config key required");
        if (key.startsWith("db.")) throw new SQLException("DB lookup not implemented");
        return "value-" + key;
    }

    // Multi-catch: two unrelated checked exceptions handled identically
    static void processConfigKey(String key) {
        try {
            String value = loadConfig(key);
            System.out.println(key + " = " + value);
        } catch (IOException | SQLException combinedException) {
            // Multi-catch: both types handled the same way — variable is final here
            System.out.println("Config retrieval failed [" +
                combinedException.getClass().getSimpleName() + "]: " +
                combinedException.getMessage());
        }
    }

    public static void main(String[] args) {

        System.out.println("=== Catch block widening via hierarchy ===");
        demonstrateCatchWidening("report.missing");
        demonstrateCatchWidening("report.csv");

        System.out.println();

        System.out.println("=== Multi-catch with unrelated checked exceptions ===");
        processConfigKey("app.name");
        processConfigKey(null);
        processConfigKey("db.host");
    }
}

Output:
=== Catch block widening via hierarchy ===
Specific handler — file missing: File not found: report.missing
General I/O handler: Generic I/O failure on: report.csv

=== Multi-catch with unrelated checked exceptions ===
app.name = value-app.name
Config retrieval failed [IOException]: Config key required
Config retrieval failed [SQLException]: DB lookup not implemented

RuntimeException in the Hierarchy

RuntimeException sits between Exception and all unchecked exception types. Its position in the tree is what makes the whole checked/unchecked distinction work — the compiler looks at whether an exception's class is a subtype of RuntimeException to decide whether to enforce handling.

Java

Try it out

// File: RuntimeHierarchyDemo.java

import java.util.List;
import java.util.Map;

public class RuntimeHierarchyDemo {

    record Product(String id, String name, double price) {}

    // IllegalArgumentException: subtype of RuntimeException — unchecked
    // Used for contract violations — callers who pass bad arguments should fix their code
    static Product validateProduct(String id, String name, double price) {
        if (id == null || id.isBlank()) {
            throw new IllegalArgumentException("Product ID must not be blank");
        }
        if (price < 0) {
            throw new IllegalArgumentException("Price cannot be negative: " + price);
        }
        return new Product(id, name, price);
    }

    // IllegalStateException: subtype of RuntimeException — unchecked
    // Used when the object is in the wrong state for the requested operation
    static class OrderProcessor {
        private boolean initialized = false;
        private String currentOrderId = null;

        void initialize() { this.initialized = true; }

        void startOrder(String orderId) {
            if (!initialized) {
                // Calling startOrder before initialize() is an object lifecycle error
                throw new IllegalStateException(
                    "OrderProcessor must be initialized before starting an order");
            }
            this.currentOrderId = orderId;
        }

        String getCurrentOrderId() {
            if (currentOrderId == null) {
                throw new IllegalStateException("No active order — call startOrder() first");
            }
            return currentOrderId;
        }
    }

    // UnsupportedOperationException: subtype of RuntimeException
    // Thrown by Collections.unmodifiableList and similar read-only views
    static void demonstrateUnsupportedOp() {
        List<String> readOnly = List.of("spring", "kafka", "redis");
        try {
            readOnly.add("docker"); // List.of() does not support mutation
        } catch (UnsupportedOperationException uoe) {
            System.out.println("Cannot modify immutable list: " + uoe.getClass().getSimpleName());
        }
    }

    public static void main(String[] args) {

        System.out.println("=== IllegalArgumentException (contract violation) ===");
        try {
            validateProduct(null, "Laptop", 45000);
        } catch (IllegalArgumentException iae) {
            System.out.println("Caught: " + iae.getMessage());
        }
        Product valid = validateProduct("P001", "Laptop", 45000);
        System.out.println("Valid product created: " + valid);

        System.out.println();

        System.out.println("=== IllegalStateException (lifecycle violation) ===");
        OrderProcessor processor = new OrderProcessor();
        try {
            processor.startOrder("ORD-9821"); // not initialized yet
        } catch (IllegalStateException ise) {
            System.out.println("Caught: " + ise.getMessage());
        }
        processor.initialize();
        processor.startOrder("ORD-9821");
        System.out.println("Active order: " + processor.getCurrentOrderId());

        System.out.println();

        System.out.println("=== UnsupportedOperationException (read-only view) ===");
        demonstrateUnsupportedOp();
    }
}

Output:
=== IllegalArgumentException (contract violation) ===
Caught: Product ID must not be blank
Valid product created: Product[id=P001, name=Laptop, price=45000.0]

=== IllegalStateException (lifecycle violation) ===
Caught: OrderProcessor must be initialized before starting an order
Active order: ORD-9821

=== UnsupportedOperationException (read-only view) ===
Cannot modify immutable list: UnsupportedOperationException

How Exception Matching Works Internally

The JVM uses instanceof checks to match thrown exceptions against catch blocks. It evaluates each catch clause from top to bottom and executes the first block whose declared type is a supertype of (or the same type as) the thrown exception.

CATCH BLOCK MATCHING — JVM evaluation order:

  thrown: FileNotFoundException (extends IOException extends Exception)

  try block
    catch (NullPointerException e) → FileNotFoundException instanceof NPE? NO
    catch (FileNotFoundException e) → FileNotFoundException instanceof FNFE? YES → EXECUTE
    catch (IOException e)           → never reached
    catch (Exception e)             → never reached

  thrown: SocketException (extends IOException extends Exception)

  try block
    catch (NullPointerException e) → SocketException instanceof NPE? NO
    catch (FileNotFoundException e) → SocketException instanceof FNFE? NO
    catch (IOException e)           → SocketException instanceof IOException? YES → EXECUTE
    catch (Exception e)             → never reached

COMPILER ENFORCEMENT OF ORDER:
  The compiler rejects this:
    catch (IOException e)         ← general
    catch (FileNotFoundException) ← specific — already caught by IOException above
  Error: "exception FileNotFoundException has already been caught"

  Correct order — specific before general:
    catch (FileNotFoundException) ← specific first
    catch (IOException e)         ← general after

Custom Exceptions and Their Position

Where you place your custom exception class in the hierarchy is a design decision that determines what callers must do with it. This choice is one of the most important parts of designing a service or library API.

Java

Try it out

// File: CustomExceptionHierarchyDemo.java

// CHECKED: callers must handle or declare
// Use when: the failure is expected, the caller has a recovery strategy
class InsufficientStockException extends Exception {

    private final String productId;
    private final int    requested;
    private final int    available;

    InsufficientStockException(String productId, int requested, int available) {
        super(String.format("Insufficient stock for %s: requested=%d available=%d",
            productId, requested, available));
        this.productId = productId;
        this.requested = requested;
        this.available = available;
    }

    String getProductId() { return productId; }
    int    getRequested() { return requested; }
    int    getAvailable() { return available; }
}

// UNCHECKED: callers do not have to handle it
// Use when: the failure indicates a programming error or system-level problem
class CatalogConfigurationException extends RuntimeException {

    CatalogConfigurationException(String message) {
        super(message);
    }

    CatalogConfigurationException(String message, Throwable cause) {
        super(message, cause); // always pass cause when wrapping
    }
}

// UNCHECKED: wraps a lower-level failure to add domain context
// Use when: the original exception is too technical for the calling layer
class InventoryServiceException extends RuntimeException {

    private final String operationType;

    InventoryServiceException(String operationType, String message, Throwable cause) {
        super("[" + operationType + "] " + message, cause);
        this.operationType = operationType;
    }

    String getOperationType() { return operationType; }
}

Java

Try it out

// File: InventoryService.java

public class InventoryService {

    private final java.util.Map<String, Integer> stock = new java.util.HashMap<>();

    public InventoryService() {
        stock.put("P001", 10);
        stock.put("P002", 0);
        // P003 intentionally missing — simulate misconfigured product
    }

    // Throws checked InsufficientStockException — caller decides what to do when stock is low
    public void reserveStock(String productId, int quantity)
            throws InsufficientStockException {

        if (!stock.containsKey(productId)) {
            // Unchecked — this is a configuration mistake, not a runtime business condition
            throw new CatalogConfigurationException(
                "Product not found in inventory catalog: " + productId);
        }

        int available = stock.get(productId);
        if (available < quantity) {
            // Checked — caller should handle "not enough stock" as a business scenario
            throw new InsufficientStockException(productId, quantity, available);
        }

        stock.put(productId, available - quantity);
        System.out.printf("Reserved %d units of %s. Remaining: %d%n",
            quantity, productId, stock.get(productId));
    }

    public static void main(String[] args) {

        InventoryService service = new InventoryService();

        System.out.println("=== Successful reservation ===");
        try {
            service.reserveStock("P001", 3);
        } catch (InsufficientStockException ise) {
            System.out.println("Stock issue: " + ise.getMessage());
        }

        System.out.println();

        System.out.println("=== Checked exception — business condition, caller decides ===");
        try {
            service.reserveStock("P002", 5); // 0 available
        } catch (InsufficientStockException ise) {
            System.out.printf("Out of stock — product=%s requested=%d available=%d%n",
                ise.getProductId(), ise.getRequested(), ise.getAvailable());
            System.out.println("Action: adding to waitlist");
        }

        System.out.println();

        System.out.println("=== Unchecked exception — configuration error, propagates ===");
        try {
            service.reserveStock("P003", 2); // not in catalog
        } catch (CatalogConfigurationException cce) {
            // Caught here for demo — in production this would propagate to a global handler
            System.out.println("System error [" + cce.getClass().getSimpleName() + "]: " +
                cce.getMessage());
        }
    }
}

Output:
=== Successful reservation ===
Reserved 3 units of P001. Remaining: 7

=== Checked exception — business condition, caller decides ===
Out of stock — product=P002 requested=5 available=0
Action: adding to waitlist

=== Unchecked exception — configuration error, propagates ===
System error [CatalogConfigurationException]: Product not found in inventory catalog: P003

Real-World Example — Razorpay Payment Gateway Layer

A payment gateway layer at Razorpay handles multiple failure modes across different architectural layers. Each exception class is placed precisely in the hierarchy: checked exceptions for expected business failures that callers must plan for, unchecked exceptions for system conditions and programming errors that propagate to a global handler.

Java

Try it out

// File: GatewayException.java

// Base class for the entire gateway exception family
// Unchecked — payment failures propagate to a global API error handler
public class GatewayException extends RuntimeException {

    private final String errorCode;
    private final int    httpStatus;

    public GatewayException(String errorCode, int httpStatus, String message) {
        super(message);
        this.errorCode  = errorCode;
        this.httpStatus = httpStatus;
    }

    public GatewayException(
            String errorCode, int httpStatus, String message, Throwable cause) {
        super(message, cause);
        this.errorCode  = errorCode;
        this.httpStatus = httpStatus;
    }

    public String getErrorCode()  { return errorCode;  }
    public int    getHttpStatus() { return httpStatus; }
}

Java

Try it out

// File: PaymentDeclinedException.java

// Specific subclass — card declined by the issuing bank
// More specific than GatewayException; catch blocks can target this precisely
public class PaymentDeclinedException extends GatewayException {

    private final String declineReason;

    public PaymentDeclinedException(String declineReason, String orderId) {
        super("PAYMENT_DECLINED", 402,
            "Payment declined for order " + orderId + ": " + declineReason);
        this.declineReason = declineReason;
    }

    public String getDeclineReason() { return declineReason; }
}

Java

Try it out

// File: GatewayTimeoutException.java

// Another specific subclass — downstream bank/network timeout
public class GatewayTimeoutException extends GatewayException {

    private final String gatewayName;
    private final int    timeoutMillis;

    public GatewayTimeoutException(String gatewayName, int timeoutMillis, Throwable cause) {
        super("GATEWAY_TIMEOUT", 504,
            gatewayName + " did not respond within " + timeoutMillis + "ms", cause);
        this.gatewayName   = gatewayName;
        this.timeoutMillis = timeoutMillis;
    }

    public String getGatewayName()   { return gatewayName;   }
    public int    getTimeoutMillis() { return timeoutMillis; }
}

Java

Try it out

// File: PaymentController.java

public class PaymentController {

    // The hierarchy enables precise catch block targeting:
    // PaymentDeclinedException before GatewayException (subtype before supertype)
    public void processPayment(String orderId, double amount, String cardType) {

        System.out.printf("Processing: order=%s amount=Rs.%.0f card=%s%n",
            orderId, amount, cardType);

        try {
            executePayment(orderId, amount, cardType);
            System.out.println("  HTTP 200 — Payment confirmed");

        } catch (PaymentDeclinedException declined) {
            // Most specific subclass — caught first
            System.out.printf("  HTTP 402 [%s] — %s%n",
                declined.getErrorCode(), declined.getMessage());

        } catch (GatewayTimeoutException timeout) {
            // Another specific subclass — caught before the general GatewayException
            System.out.printf("  HTTP 504 [%s] — %s (retry eligible)%n",
                timeout.getErrorCode(), timeout.getMessage());

        } catch (GatewayException gateway) {
            // General gateway exception — catches anything not already caught above
            System.out.printf("  HTTP %d [%s] — %s%n",
                gateway.getHttpStatus(), gateway.getErrorCode(), gateway.getMessage());

        } catch (Exception unexpected) {
            // Absolute last resort — only for truly unexpected non-gateway failures
            System.out.printf("  HTTP 500 — Unexpected: %s%n",
                unexpected.getClass().getSimpleName());
        }
    }

    private void executePayment(String orderId, double amount, String cardType) {
        if ("DECLINED-CARD".equals(cardType)) {
            throw new PaymentDeclinedException("Insufficient funds", orderId);
        }
        if ("TIMEOUT-CARD".equals(cardType)) {
            throw new GatewayTimeoutException("HDFC-GATEWAY", 5000,
                new RuntimeException("Connection timed out"));
        }
        if (amount > 200_000) {
            throw new GatewayException("LIMIT_EXCEEDED", 422,
                "Transaction amount exceeds per-transaction limit");
        }
    }

    public static void main(String[] args) {
        PaymentController controller = new PaymentController();

        controller.processPayment("ORD-001", 2499.0,   "VISA");
        System.out.println();
        controller.processPayment("ORD-002", 5000.0,   "DECLINED-CARD");
        System.out.println();
        controller.processPayment("ORD-003", 1299.0,   "TIMEOUT-CARD");
        System.out.println();
        controller.processPayment("ORD-004", 250_000.0, "AMEX");
    }
}

Output:
Processing: order=ORD-001 amount=Rs.2499 card=VISA
  HTTP 200 — Payment confirmed

Processing: order=ORD-002 amount=Rs.5000 card=DECLINED-CARD
  HTTP 402 [PAYMENT_DECLINED] — Payment declined for order ORD-002: Insufficient funds

Processing: order=ORD-003 amount=Rs.1299 card=TIMEOUT-CARD
  HTTP 504 [GATEWAY_TIMEOUT] — HDFC-GATEWAY did not respond within 5000ms (retry eligible)

Processing: order=ORD-004 amount=Rs.250000 card=AMEX
  HTTP 422 [LIMIT_EXCEEDED] — Transaction amount exceeds per-transaction limit

Performance Considerations

All exception construction involves one expensive operation: capturing the stack trace. This happens at the moment the new SomeException(...) object is created — not when it is thrown, not when it is caught, not when printStackTrace() is called. The stack trace is a snapshot of all active method frames on the calling thread at creation time.

EXCEPTION CONSTRUCTION COST:

  new RuntimeException("message")
    → JVM walks the current call stack
    → Creates a StackTraceElement for each frame
    → 200-frame stack → 200 objects allocated
    → Expensive: microseconds, not nanoseconds

  Implications:
    Creating exceptions in tight loops degrades performance significantly.
    "Exceptional" means rare — not "every iteration that finds no result".
    For control flow (not-found, no-data), return Optional or null — not exceptions.

  SUPPRESSING STACK TRACE (valid for control-flow use cases in frameworks):
    new RuntimeException("message") {
        @Override
        public synchronized Throwable fillInStackTrace() {
            return this; // skips stack capture — exception creation becomes cheap
        }
    };
    Only use this in frameworks where exception objects serve as signals, not diagnostics.

Best Practices

Place custom exceptions at exactly the right level in the hierarchy. Extending Exception (checked) signals "this is a recoverable business condition — callers must have a plan." Extending RuntimeException (unchecked) signals "this is a system problem or programming error — handle at the boundary, not everywhere." A single application typically needs both, and mixing them — making a routine business failure unchecked, or making a programming error checked — pollutes every caller with unnecessary catch blocks or silently swallows errors.

Design exception hierarchies with a shared base class for each subsystem. A payment service should have a PaymentException base, under which PaymentDeclinedException, GatewayTimeoutException, and FraudDetectionException sit. This lets callers catch the base class when they only care that "something payment-related failed," and target specific subclasses when they need different handling per failure mode. This is the same pattern the JDK itself uses: IOException as a base for all java.io failures.

Always add a cause when wrapping exceptions. throw new ServiceException("payment failed", originalSqlException) preserves the full diagnostic chain. Without passing the cause, getCause() returns null and the root cause disappears from logs. Production debugging without the cause chain is dramatically harder — this is the single most impactful exception-handling rule in real codebases.

Keep the exception hierarchy shallow. Three levels below Exception is almost always enough: a subsystem base, a category (business vs system), and specific types. Hierarchies deeper than that require developers to memorise too much to use the catch blocks correctly. A hierarchy nobody can remember is not used correctly.

Common Mistakes

Mistake 1 — Putting a Specific Catch Block After a General One

Java

Try it out

// WRONG — compiler rejects this: FileNotFoundException already caught by IOException
try {
    openFile("config.yml");
} catch (IOException ioe) {
    System.out.println("IO error");
} catch (FileNotFoundException fnfe) {
    // This line never compiles — compiler flags it as unreachable
    System.out.println("File missing");
}

// CORRECT — specific (deeper in tree) always goes first
try {
    openFile("config.yml");
} catch (FileNotFoundException fnfe) {
    System.out.println("File missing: " + fnfe.getMessage());
} catch (IOException ioe) {
    System.out.println("Other IO error: " + ioe.getMessage());
}

Mistake 2 — Making Domain Exceptions Extend Exception When They Should Extend RuntimeException

Java

Try it out

// WRONG — OrderNotFoundException is a checked exception
// Every service method that might not find an order now requires
// throws OrderNotFoundException in its signature, polluting the entire call chain
class OrderNotFoundException extends Exception { // checked — forces every caller to declare
    OrderNotFoundException(String orderId) {
        super("Order not found: " + orderId);
    }
}

// This ripples up:
public Order getOrder(String orderId) throws OrderNotFoundException { ... }
public Invoice generateInvoice(String orderId) throws OrderNotFoundException { ... }
public void sendConfirmation(String orderId) throws OrderNotFoundException { ... }
// Every method that uses orderId now carries the checked exception declaration

// CORRECT — for a "not found" that callers handle at the controller layer:
class OrderNotFoundException extends RuntimeException { // unchecked
    OrderNotFoundException(String orderId) {
        super("Order not found: " + orderId);
    }
}
// Now only the controller catches it — business logic methods stay clean

Mistake 3 — Losing the Cause When Wrapping

Java

Try it out

// WRONG — original SQLException is swallowed
// getCause() returns null, root cause never appears in logs
public void saveOrder(Order order) {
    try {
        repository.save(order);
    } catch (java.sql.SQLException sqlEx) {
        throw new InventoryServiceException("SAVE", "Failed to save order", null);
        //                                                       cause is null ^^^
    }
}

// CORRECT — always pass the original exception as the second argument
public void saveOrder(Order order) {
    try {
        repository.save(order);
    } catch (java.sql.SQLException sqlEx) {
        throw new InventoryServiceException("SAVE", "Failed to save order", sqlEx);
        // Full chain in logs: InventoryServiceException → SQLException → DB error
    }
}

Mistake 4 — Creating Redundant Exception Classes That Add No Information

Java

Try it out

// WRONG — just wraps RuntimeException with no additional state or meaning
class GeneralException extends RuntimeException {
    GeneralException(String message) { super(message); }
}

// This adds nothing over throwing RuntimeException directly.
// Exception classes earn their existence by carrying domain-specific fields:
// orderId, errorCode, httpStatus, customerId — something the message string alone cannot.

// CORRECT — every custom exception class should have at least one domain-specific field
class OrderProcessingException extends RuntimeException {
    private final String orderId;
    private final String failureStage; // "VALIDATION", "PAYMENT", "FULFILMENT"

    OrderProcessingException(String orderId, String failureStage, String message, Throwable cause) {
        super(message, cause);
        this.orderId      = orderId;
        this.failureStage = failureStage;
    }

    String getOrderId()      { return orderId;      }
    String getFailureStage() { return failureStage; }
}

Interview Questions

Q1. What is the root of the Java exception hierarchy and what does it provide?

java.lang.Throwable is the root. Every class that can be thrown or caught in Java extends it directly or indirectly. Throwable provides four core fields: a String message describing the failure, a Throwable cause for exception chaining, a StackTraceElement[] array captured at construction time, and a Throwable[] array of suppressed exceptions added by try-with-resources. The key methods are getMessage(), getCause(), getStackTrace(), printStackTrace(), and getSuppressed().

Q2. How does the JVM decide which catch block handles a thrown exception?

The JVM evaluates catch clauses from top to bottom using instanceof checks. The first catch block whose declared type is the same as or a supertype of the thrown exception's class is selected for execution. This is why catch blocks must be ordered from most specific to most general — a catch (IOException e) before catch (FileNotFoundException e) makes the FileNotFoundException block unreachable, because FileNotFoundException is-a IOException and the first block would match. The compiler detects and rejects this ordering.

Q3. What is the difference between checked and unchecked exceptions in terms of their position in the hierarchy?

The position in the hierarchy is the mechanism: any class that extends Exception without going through RuntimeException is a checked exception. Any class that extends RuntimeException (which extends Exception) is unchecked. The compiler uses this structural property to enforce handling — if a method throws a checked exception, every calling method must either surround the call with try-catch or declare throws in its own signature. RuntimeException and Error subclasses are exempt from this enforcement.

Q4. If you create a custom exception, should it extend Exception or RuntimeException, and why?

The decision is about recoverability and caller responsibility. Extend Exception (checked) when the failure represents an expected, recoverable business condition that callers should explicitly plan for — InsufficientStockException, PaymentDeclinedException. Extend RuntimeException (unchecked) when the failure represents a programming error, configuration problem, or system failure that callers should not need to handle case-by-case — CatalogConfigurationException, InvalidArgumentException. Choosing wrongly pollutes APIs: checked exceptions for routine conditions force every intermediate method to carry the throws declaration; unchecked exceptions for serious business failures hide conditions callers need to handle.

Q5. Why must catch blocks be ordered from most specific to most general?

Because the JVM evaluates catch blocks top-to-bottom using instanceof matching, and instanceof returns true for all supertypes. If catch (Exception e) appears before catch (IOException e), every IOException matches the first block because IOException is-a Exception. The IOException block never executes. The Java compiler detects this as unreachable code and treats it as a compile error: "exception IOException has already been caught." The ordering rule is enforced at compile time, not runtime.

Q6. What is exception chaining and why does the cause matter in production?

Exception chaining is the practice of wrapping one exception inside another by passing the original as the cause argument to the new exception's constructor. new ServiceException("failed", originalSqlException) stores the SQLException as the cause. getCause() returns it. printStackTrace() prints the entire chain. In production, the root cause is what actually went wrong — "failed to save order" is not actionable; "ORA-00942: table or view does not exist" tells you exactly what to fix. Wrapping exceptions without preserving the cause destroys diagnostic information and makes debugging dramatically harder.

Q7. How does the exception hierarchy enable a global exception handler pattern?

A global exception handler (like a Spring Boot @ControllerAdvice, or a Thread.UncaughtExceptionHandler) catches exception types and maps them to responses. Because every domain exception extends a common base — say GatewayException — the global handler can catch (GatewayException e) and map e.getHttpStatus() to the HTTP response code. More specific subclasses like PaymentDeclinedException and GatewayTimeoutException can be caught individually for specific mappings, while the base class catches any unrecognised subtype. This hierarchy-aware pattern is exactly how Spring Boot's exception handling works internally.

FAQs

What is java.lang.Throwable and why do we rarely use it directly?

Throwable is the root class of the exception hierarchy — the only type that can appear after throw or in a catch clause. We rarely use it directly because catching Throwable swallows both Exception (application failures) and Error (JVM failures) through one handler. This makes it impossible to distinguish recoverable failures from catastrophic ones. Framework code uses Throwable in thread pool workers and test frameworks where intercepting everything is intentional. In business logic, it signals unaddressed design problems.

Why does NumberFormatException extend IllegalArgumentException instead of Exception directly?

NumberFormatException is thrown when a string passed to a number-parsing method has invalid format — a contract violation by the caller. It shares its cause and handling strategy with IllegalArgumentException (bad arguments violate method contracts). Placing it under IllegalArgumentException means that a catch (IllegalArgumentException e) block already handles both, and code that specifically cares about number format issues can target NumberFormatException more precisely. This is the hierarchy working as designed: related failures cluster together.

What is the difference between Exception and RuntimeException?

RuntimeException extends Exception. The only structural difference is that the Java compiler treats RuntimeException and all its subclasses as unchecked — it does not require callers to handle or declare them. Exception subclasses that do not go through RuntimeException are checked — the compiler enforces handling. In terms of code behaviour at runtime, there is no difference: both are caught by catch (Exception e), both carry messages and causes, and both produce stack traces.

Is it possible to create a hierarchy of custom exceptions?

Yes, and it is the recommended pattern for large codebases. Define a module-level base exception (PaymentException extends RuntimeException), then specific subclasses below it (PaymentDeclinedException extends PaymentException). Callers that handle any payment failure use catch (PaymentException e). Callers that differentiate between specific failures use catch (PaymentDeclinedException e) first. This mirrors the JDK design: IOException as a base, FileNotFoundException and SocketException as specific subtypes.

Can I catch multiple exception types that are unrelated in the hierarchy?

Yes — multi-catch syntax handles this: catch (IOException | SQLException exception). The two types do not need to share a common ancestor below Throwable (other than Throwable itself). The variable in a multi-catch block is implicitly final — you cannot reassign it. Multi-catch is appropriate when two different exception types genuinely require identical handling and you want to avoid duplicating the catch body.

Does catching a supertype affect the stack trace or exception object?

No. Catching IOException instead of FileNotFoundException does not modify the exception object in any way. The exception is the same object — same class, same message, same cause, same stack trace — regardless of which catch clause intercepts it. The catch clause only determines which block of code runs; it does not alter the exception itself.

Summary

The Java exception hierarchy is a class tree rooted at Throwable, branching into Error (JVM failures) and Exception (application failures), with RuntimeException as the dividing line between checked and unchecked within the Exception branch. Every decision that seems like a Java syntax rule — catch ordering, throws declarations, compiler errors about unhandled exceptions — is a direct consequence of this tree structure combined with instanceof matching.

The hierarchy serves three practical purposes: it defines what the compiler requires, it determines which catch block fires, and it communicates intent to callers. A well-designed exception hierarchy for a module has a base class, specific subclasses with domain-relevant fields, checked exceptions for recoverable business conditions, unchecked exceptions for programming errors and system failures, and a cause preserved on every wrapped exception.

For interviews, the questions about hierarchy almost always test whether you can explain checked versus unchecked in terms of tree position, articulate why catch ordering is specific-before-general, and describe how exception chaining works through the cause reference. These three questions together cover what most companies actually care about.

What to Read Next

Continue Learning Exception Handling

Next Step

Checked vs Unchecked Exceptions

Learn the difference between checked and unchecked exceptions.

→

Custom Exceptions

Learn how to create your own exception type.

→

Semaphore

Learn how to limit how many threads can access a resource at once.

→

Common Java Exceptions

Learn the most common exceptions you'll run into in Java.

→

←

PreviousException vs Error

NextChecked vs Unchecked Exceptions

→