Java Exception Reference

This is a searchable reference for Java’s Throwable hierarchy — the standard-library tree of checked exceptions, unchecked RuntimeExceptions, and Errors. For each class it shows the direct parent, whether it is checked or unchecked, and the typical cause, so you can decide what to catch and what to let propagate.

The hierarchy at a glance

Throwable
├── Error                          ← JVM-level; do not catch
│   ├── OutOfMemoryError
│   ├── StackOverflowError
│   └── AssertionError
└── Exception                      ← Recoverable conditions
    ├── RuntimeException           ← Unchecked; compiler silent
    │   ├── NullPointerException
    │   ├── IllegalArgumentException
    │   │   └── NumberFormatException
    │   ├── IndexOutOfBoundsException
    │   │   └── ArrayIndexOutOfBoundsException
    │   └── ClassCastException
    ├── IOException                ← Checked; must declare or catch
    │   ├── FileNotFoundException
    │   └── SocketException
    ├── SQLException               ← Checked
    └── CloneNotSupportedException ← Checked

Checked vs unchecked: the design intent

Checked exceptions (every Exception subclass that is not a RuntimeException) represent conditions a well-written program is expected to anticipate and recover from: a file may not exist, a network connection may fail. The compiler forces you to either handle them with try/catch or declare them with throws, making the contract visible in the method signature.

Unchecked exceptions (every RuntimeException) represent programming errors — passing a null to a method that requires a non-null value, indexing past the end of an array. Because these indicate bugs rather than environmental conditions, Java’s designers did not want every call site cluttered with obligatory catch blocks for defects the programmer should simply fix.

Errors are not meant to be caught at all. When the JVM runs out of memory or a thread stack overflows, the application is in a state it cannot meaningfully recover from. Catching OutOfMemoryError and continuing is almost never correct.

Practical rules

• Catch the most specific exception that fits your recovery logic. Catching Exception as a blanket swallows unchecked bugs along with expected failures.
• Use the Extends column to trace a hierarchy: FileNotFoundException extends IOException, so catch (IOException e) already covers file-not-found cases — no need for two separate blocks.
• Multi-catch (Java 7+) lets you handle several unrelated checked exceptions in one block: catch (IOException | SQLException e).
• Never swallow exceptions silently: catch (Exception e) {} hides real failures. At minimum log the exception before re-throwing or returning a default.

Worked example

A method declaring its checked exception and a caller handling the family:

void load(Path p) throws IOException {     // checked: must declare
    Files.readAllBytes(p);                 // may throw NoSuchFileException (subclass)
}

try {
    load(path);
    int n = Integer.parseInt(input);       // may throw NumberFormatException (unchecked)
} catch (IOException e) {                  // also catches FileNotFoundException, NoSuchFileException
    log.warn("io failed", e);
} catch (NumberFormatException e) {        // unchecked — optional but recommended
    n = 0;
}

Because NumberFormatException is unchecked the compiler would not complain if you omitted that catch, but doing so lets bad input crash the call. The IOException catch covers the entire family of IO exceptions without naming each one.

Everything runs in your browser; nothing is uploaded.