Mastering Java Exception Hierarchy: From Checked to Unchecked and Best Practices

Core Principle

Java's exception system is a fundamental topic for backend developers and interview candidates, testing not only syntax knowledge of try‑catch but also understanding of Checked Exception and Unchecked Exception design intentions and real‑world handling techniques.

1. Exception Inheritance Hierarchy

Throwable
├── Error (JVM‑level errors, cannot be handled)
│   ├── OutOfMemoryError
│   ├── StackOverflowError
│   └── ...
└── Exception (can be caught)
    ├── RuntimeException (Unchecked)
    │   ├── NullPointerException
    │   ├── IndexOutOfBoundsException
    │   ├── ClassCastException
    │   ├── IllegalArgumentException
    │   └── ...
    └── Other Exceptions (Checked)
        ├── IOException
        ├── SQLException
        ├── ClassNotFoundException
        └── ...

2. Checked Exception

The compiler forces callers to either catch the exception with try‑catch or declare it with throws. Any subclass of Exception that does not extend RuntimeException is a checked exception.

// IOException is a checked exception and must be handled
public void readFile(String path) throws IOException {
    Files.readAllBytes(Paths.get(path));
}

// Or handle it locally
public void readFile(String path) {
    try {
        Files.readAllBytes(Paths.get(path));
    } catch (IOException e) {
        log.error("File read failed", e);
        throw new RuntimeException("File read failed", e); // wrap as unchecked
    }
}

Design intent: Force developers to explicitly consider predictable external errors such as I/O, network, or database failures, preventing silent neglect.

3. Unchecked Exception

Subclasses of RuntimeException are not enforced by the compiler. They usually represent programming bugs (null pointer, array index out of bounds, illegal casts, etc.). The correct response is to fix the code rather than catch them.

// NullPointerException is unchecked; no try‑catch required
String s = null;
s.length(); // throws NullPointerException at runtime

4. Error

Error

denotes severe JVM problems (e.g., OutOfMemoryError, StackOverflowError) that applications typically cannot recover from and therefore should not be caught, except in very special monitoring scenarios.

5. Best Practices for Exception Handling

Never swallow exceptions: At minimum, log the error with context.

Use specific catches: catch (IOException e) is preferred over catch (Exception e) to avoid masking other issues.

Preserve cause chain: When wrapping an exception, pass the original cause to retain stack‑trace information.

Define custom business exceptions: Create a unified base class extending RuntimeException to avoid polluting method signatures with throws.

public class BusinessException extends RuntimeException {
    private final String errorCode;
    public BusinessException(String errorCode, String message) {
        super(message);
        this.errorCode = errorCode;
    }
    public BusinessException(String errorCode, String message, Throwable cause) {
        super(message, cause);
        this.errorCode = errorCode;
    }
    public String getErrorCode() { return errorCode; }
}

High‑Frequency Q&A

Q: What is the difference between throws and throw?

A: throw manually raises an exception instance at runtime; throws declares in a method signature which checked exceptions may propagate, informing callers they must handle or re‑declare them.

Q: Can I throw an exception inside a finally block?

A: Yes, but it will suppress any exception from the try or catch block, causing the original error to be lost—generally discouraged unless deliberately handled with thorough logging.

Q: How does try‑with‑resources handle multiple exceptions?

A: The exception from the try block becomes the primary exception; exceptions thrown by close() are added as suppressed exceptions accessible via Throwable.getSuppressed(), preserving the full exception chain.

Interview Answer Template

Java's exception hierarchy is rooted at Throwable , which splits into Error (JVM‑level, not to be caught) and Exception . Exception further divides into checked exceptions (must be declared or caught) and unchecked exceptions ( RuntimeException subtree). Checked exceptions express expected external failures; unchecked exceptions represent programming bugs and should be fixed rather than caught. In practice, define custom business exceptions extending RuntimeException to keep method signatures clean, always log caught exceptions, and propagate the original cause when wrapping.