What is the Throwable class and the exception hierarchy?

The hierarchy:

• Throwable – root class. Only Throwable subclasses can be thrown.
• Error – serious JVM failures: OutOfMemoryError, StackOverflowError. Applications should not catch these.
• Exception – application-level problems.
• Checked (non-Runtime): IOException, SQLException. Compiler enforces handling.
• Unchecked (RuntimeException): NullPointerException, IllegalArgumentException. Compiler does not enforce.

What does the hierarchy look like?

java.lang.Object
  └── java.lang.Throwable
        ├── java.lang.Error                    (do not catch)
        │     ├── OutOfMemoryError
        │     ├── StackOverflowError
        │     └── NoClassDefFoundError
        └── java.lang.Exception                (catch and handle)
              ├── IOException                   (checked)
              ├── SQLException                  (checked)
              ├── InterruptedException           (checked)
              └── java.lang.RuntimeException    (unchecked)
                    ├── NullPointerException
                    ├── IllegalArgumentException
                    ├── IndexOutOfBoundsException
                    ├── ClassCastException
                    └── ArithmeticException

What is the difference between checked and unchecked?

// CHECKED: compiler forces you to handle it
public void readFile() throws IOException {    // must declare
    BufferedReader reader = new BufferedReader(new FileReader("accounts.csv"));
    // ...
}

// Or catch it:
public void readFileSafe() {
    try {
        BufferedReader reader = new BufferedReader(new FileReader("accounts.csv"));
    } catch (IOException e) {
        log.severe("File not found: " + e.getMessage());
    }
}

// UNCHECKED: compiler does not force handling
public void process(Account account) {
    account.getBalance();  // throws NPE if account is null – no compiler warning
}

| Feature | Checked | Unchecked |
|---|---|---|
| Superclass | Exception (not RuntimeException) | RuntimeException |
| Compiler enforces | Yes (try-catch or throws) | No |
| Examples | IOException, SQLException | NullPointerException, IllegalArgumentException |
| Represents | External failures (I/O, network, DB) | Programming bugs (null, bad args) |
| Handling | Recover or propagate | Fix the code |

When should you use checked vs unchecked in your own code?

// Checked: caller CAN recover from this
public class InsufficientFundsException extends Exception {
    public InsufficientFundsException(String message) {
        super(message);
    }
}

// Unchecked: programming error, caller should fix the code
public class InvalidAccountIdException extends RuntimeException {
    public InvalidAccountIdException(String message) {
        super(message);
    }
}

What should you NEVER catch?

// NEVER catch Error – JVM is in an unrecoverable state
try {
    // ...
} catch (OutOfMemoryError e) {  // BAD: JVM cannot allocate memory
    // What can you do here? Nothing reliable.
}

// NEVER catch Throwable – catches both Error and Exception
try {
    // ...
} catch (Throwable t) {  // BAD: hides OutOfMemoryError, StackOverflowError
}

What are common mistakes?

• Catching Exception broadly. catch (Exception e) catches everything including NPE. Catch specific exceptions.
• Empty catch block. catch (IOException e) { } silently swallows the error. Always log.
• Using checked exceptions for programming errors. NPE-style bugs should be unchecked. Checked exceptions are for recoverable external failures.
• Catching Error. The JVM is broken. Let it crash and restart.

What should a senior engineer know?

• Multi-catch (Java 7+): catch (IOException | SQLException e) catches either type.
• try-with-resources (Java 7+): auto-closes resources. try (var conn = getConnection()) { ... }.
• Suppressed exceptions: When try-with-resources auto-close throws after the try block threw, the close exception is suppressed. Access via e.getSuppressed().
• Spring @Transactional rolls back on unchecked exceptions by default. Checked exceptions do not trigger rollback unless configured.