Exception Handling

What is an Exception?

An exception is an object that represents an abnormal condition during program execution. When something goes wrong — a file doesn't exist, a network connection drops, someone passes null where a value was expected — the JVM (or your own code) throws an exception object. This interrupts the normal execution flow immediately.

Without exception handling, that interruption crashes the program and the user sees a raw stack trace. With exception handling, you can catch the exception, react to it in a controlled way, and decide whether to recover, report, or propagate it up the call stack.

// Without exception handling: program crashes
int[] numbers = {1, 2, 3};
System.out.println(numbers[10]);  // ← THROWS ArrayIndexOutOfBoundsException
System.out.println("this never runs");

// Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException:
// Index 10 out of bounds for length 3

// With exception handling: you control what happens
try {
    System.out.println(numbers[10]);  // ← throws, jumps to catch immediately
} catch (ArrayIndexOutOfBoundsException e) {
    System.out.println("Index does not exist: " + e.getMessage());
}
System.out.println("this DOES run");  // execution continues normally

Throwing vs catching

Throwing means signalling that something went wrong. You use the throw keyword with an exception object. Execution at the throw site stops immediately — no more code in that method runs after a throw.

Catching means intercepting a thrown exception before it crashes the program. You use try { } catch { }. The catch block only runs if an exception of the matching type was thrown inside the try block.

// THROWING — you signal the problem
public void validateAge(int age) {
    if (age < 0)
        throw new IllegalArgumentException("Age cannot be negative: " + age);
    // nothing below this line runs if age < 0
    this.age = age;
}

// CATCHING — you handle the problem
try {
    validateAge(-5);
} catch (IllegalArgumentException e) {
    System.out.println("Bad input: " + e.getMessage());
    // decide: fix it, log it, re-throw it, show a message to the user...
}

Runtime exceptions vs compile-time exceptions

Java distinguishes two kinds:

• Checked exceptions — the compiler knows this operation can fail and forces you to deal with it. You must either catch it or declare it with throws in the method signature. Examples: reading a file (IOException), querying a database (SQLException). The idea: these are recoverable external failures that the caller should be aware of.
• Unchecked exceptions (runtime exceptions) — the compiler does not force you to handle them. They represent programming bugs or violated preconditions: NullPointerException, IllegalArgumentException, IndexOutOfBoundsException. The idea: if your code is correct, these shouldn't happen — so forcing every caller to wrap every method call in try-catch would be noise.

// CHECKED — compiler rejects this without try-catch or throws declaration
public void readFile(String path) {
    new FileReader(path);  // compile error: FileNotFoundException not handled
}

// UNCHECKED — compiles fine, but may blow up at runtime
public void printLength(String s) {
    System.out.println(s.length());  // NullPointerException if s is null
}

The Exception Hierarchy

In Java, everything throwable is a subclass of Throwable. The hierarchy determines what you must handle, what you can ignore, and what you should never catch.

/*
 *  Throwable
 *  ├── Error                  ← JVM problems, do NOT catch
 *  │   ├── OutOfMemoryError
 *  │   ├── StackOverflowError
 *  │   └── AssertionError
 *  │
 *  └── Exception
 *      ├── IOException         ← CHECKED: compiler forces you to handle
 *      │   ├── FileNotFoundException
 *      │   └── SocketException
 *      ├── SQLException        ← CHECKED
 *      ├── ClassNotFoundException ← CHECKED
 *      │
 *      └── RuntimeException    ← UNCHECKED: optional to handle
 *          ├── NullPointerException
 *          ├── IllegalArgumentException
 *          ├── IllegalStateException
 *          ├── UnsupportedOperationException
 *          ├── ArithmeticException
 *          ├── ClassCastException
 *          ├── IndexOutOfBoundsException
 *          │   └── ArrayIndexOutOfBoundsException
 *          └── NumberFormatException
 */

try / catch / finally

try {
    // code that may throw
    int result = 100 / divisor;
    processResult(result);

} catch (ArithmeticException e) {
    // specific exception first
    log.error("Division failed", e);

} catch (IllegalArgumentException | IllegalStateException e) {
    // multi-catch: same handler for two unrelated exceptions (Java 7+)
    log.warn("Validation error", e);

} catch (Exception e) {
    // general catch last — order matters: most specific first
    log.error("Unexpected error", e);
    throw e;  // re-throw if you can't handle it here

} finally {
    // ALWAYS runs — with or without exception, even with return in try/catch
    // Only exception: System.exit() or JVM crash
    cleanup();
}

// ❌ Unreachable catch — Exception catches everything above it
catch (Exception e)              { }
catch (IOException e)            { }  // compile error: already caught by Exception

// ✅ Most specific first, most general last
catch (FileNotFoundException e)   { }  // subtype of IOException
catch (IOException e)            { }  // catches remaining IO exceptions
catch (Exception e)              { }  // last resort

try-with-resources — automatic close (Java 7+)

Any object implementing AutoCloseable can go in the parentheses. It is closed automatically at the end of the block, even if an exception is thrown.

// ❌ Old way: fragile, easy to forget close in the exception path
Connection conn = null;
try {
    conn = dataSource.getConnection();
    // use conn...
} finally {
    if (conn != null) try { conn.close(); } catch (SQLException ignored) {}
}

// ✅ try-with-resources: clean, guaranteed close, multiple resources OK
try (Connection conn   = dataSource.getConnection();
     PreparedStatement ps = conn.prepareStatement("SELECT 1");
     ResultSet rs         = ps.executeQuery()) {

    while (rs.next()) { ... }

} catch (SQLException e) {
    // conn, ps, rs all closed before we get here — in reverse order
    throw new RuntimeException("DB query failed", e);
}

Checked vs Unchecked Exceptions

Checked — compiler enforces handling

// Checked exceptions extend Exception (but NOT RuntimeException)
// You MUST either catch them or declare them with throws

// Option 1: catch and handle
public String readFile(String path) {
    try (BufferedReader r = new BufferedReader(new FileReader(path))) {
        return r.lines().collect(Collectors.joining("\n"));
    } catch (IOException e) {
        log.error("Cannot read {}", path, e);
        return "";
    }
}

// Option 2: declare and let the caller decide
public String readFile(String path) throws IOException {
    try (BufferedReader r = new BufferedReader(new FileReader(path))) {
        return r.lines().collect(Collectors.joining("\n"));
    }
}

Unchecked — for programming errors and validation failures

// Unchecked = extend RuntimeException
// Use for: invalid arguments, broken preconditions, bugs
// The compiler does NOT force callers to handle them

public void setAge(int age) {
    if (age < 0 || age > 150)
        throw new IllegalArgumentException("Invalid age: " + age);
    this.age = age;
}

// Most useful unchecked exceptions from the JDK:
throw new IllegalArgumentException("bad input");   // invalid parameter value
throw new IllegalStateException("not connected");    // method called at wrong time
throw new NullPointerException("name is null");      // explicit null check (rare)
throw new UnsupportedOperationException("not implemented"); // stub
throw new IndexOutOfBoundsException("index: " + i);  // invalid index

// Objects.requireNonNull — standard null guard (throws NullPointerException)
this.name = Objects.requireNonNull(name, "name must not be null");

Custom Exceptions

Create domain-specific exceptions when standard JDK types don't convey enough meaning. The rule: extend RuntimeException for programming errors / unrecoverable situations; extend Exception for recoverable situations where callers should be forced to handle.

// Custom unchecked exception — callers don't have to catch it
public class InsufficientFundsException extends RuntimeException {
    private final double available;
    private final double requested;

    public InsufficientFundsException(double available, double requested) {
        super(String.format("Insufficient funds: available=%.2f, requested=%.2f",
                            available, requested));
        this.available = available;
        this.requested = requested;
    }

    // Always provide a cause-accepting constructor for exception chaining
    public InsufficientFundsException(double available, double requested,
                                       Throwable cause) {
        super(String.format("Insufficient funds: available=%.2f, requested=%.2f",
                            available, requested), cause);
        this.available = available;
        this.requested = requested;
    }

    public double getAvailable() { return available; }
    public double getRequested() { return requested; }
}

// Usage — caller gets rich context, not just a message string
public void withdraw(double amount) {
    if (amount > balance)
        throw new InsufficientFundsException(balance, amount);
    balance -= amount;
}

try {
    account.withdraw(500);
} catch (InsufficientFundsException e) {
    System.out.printf("Need %.2f more%n", e.getRequested() - e.getAvailable());
}

Exception Chaining

When you catch an exception and throw a different one, always pass the original as the cause. Without it, the root cause disappears from the stack trace — a debugging nightmare.

// ❌ BAD: original cause lost — the stack trace shows only OrderException,
// you can never find out WHAT SQLException triggered it
try {
    db.save(order);
} catch (SQLException e) {
    throw new OrderException("Failed to save order");  // cause dropped!
}

// ✅ GOOD: wrap and preserve the cause
try {
    db.save(order);
} catch (SQLException e) {
    throw new OrderException("Failed to save order", e);  // e is the cause
}

// When you inspect the exception, the full chain is visible:
// OrderException: Failed to save order
//   Caused by: java.sql.SQLException: Connection refused
//   Caused by: java.net.ConnectException: Connection refused

// Retrieve the cause programmatically:
e.getCause();           // direct cause
ExceptionUtils.getRootCause(e);  // root cause (Apache Commons)

Common Exceptions Reference

Common Pitfalls

// ❌ Empty catch: the error disappears, the bug hides forever
try {
    processOrder(order);
} catch (Exception e) {
    // nothing
}

// ✅ At minimum: log. If you truly can't handle it, re-throw.
try {
    processOrder(order);
} catch (OrderException e) {
    log.error("Order processing failed for orderId={}", order.getId(), e);
    throw e;  // or wrap in a higher-level exception
}

// ❌ BAD: exceptions are expensive — stack trace captured on construction
try {
    int value = map.get("key").intValue();  // may NPE if key absent
} catch (NullPointerException e) {
    value = 0;  // using exception to handle "not found" case
}

// ✅ GOOD: check first, exception-free path for the common case
int value = map.getOrDefault("key", 0);

// ❌ NEVER catch Error or raw Throwable in normal application code
catch (Throwable t) { ... }  // catches OutOfMemoryError, StackOverflowError…
catch (Error e) { ... }      // the JVM is broken — you can't recover

// ✅ Only catch what you can actually handle
// Exception: frameworks (Spring, JUnit) catch Throwable intentionally — that's fine

// ❌ Root cause gone — impossible to diagnose in production
catch (SQLException e) {
    throw new ServiceException("DB error");  // no cause!
}

// ✅ Always chain the cause
catch (SQLException e) {
    throw new ServiceException("DB error", e);  // full chain preserved
}

Senior Topics: Exceptions in Modern Java

Exception handling in Streams and lambdas

Lambdas cannot throw checked exceptions — functional interface methods don't declare them. This is a real pain with streams over I/O operations.

// ❌ Doesn't compile: Files::readString throws IOException (checked)
List<String> contents = paths.stream()
    .map(Files::readString)   // compile error: unhandled IOException
    .toList();

// Option 1: wrap checked in unchecked inside the lambda
List<String> contents = paths.stream()
    .map(path -> {
        try { return Files.readString(path); }
        catch (IOException e) { throw new UncheckedIOException(e); }
    })
    .toList();

// Option 2: extract to a helper that wraps (reusable)
private static <T, R> Function<T, R> wrap(CheckedFunction<T, R> fn) {
    return t -> {
        try { return fn.apply(t); }
        catch (Exception e) { throw new RuntimeException(e); }
    };
}
// Usage: paths.stream().map(wrap(Files::readString)).toList();

// Option 3 (Java 21+): use vavr or Result types for functional error handling

Suppressed exceptions in try-with-resources

// If both the try body AND close() throw, close()'s exception is "suppressed"
// The primary exception propagates; the suppressed one is attached

try (MyResource r = new MyResource()) {
    r.riskyOperation();  // throws ExceptionA
    // r.close() called automatically → throws ExceptionB
    // ExceptionA propagates; ExceptionB is attached as suppressed
}

// Inspect suppressed exceptions:
try { ... }
catch (Exception primary) {
    for (Throwable suppressed : primary.getSuppressed()) {
        log.error("Suppressed: {}", suppressed.getMessage());
    }
    throw primary;
}

Global exception handling in Spring

// Instead of try-catch in every controller, centralise with @ControllerAdvice
@ControllerAdvice
public class GlobalExceptionHandler {

    @ExceptionHandler(InsufficientFundsException.class)
    public ResponseEntity<ErrorResponse> handle(InsufficientFundsException e) {
        return ResponseEntity
            .status(HttpStatus.UNPROCESSABLE_ENTITY)
            .body(new ErrorResponse("INSUFFICIENT_FUNDS", e.getMessage()));
    }

    @ExceptionHandler(IllegalArgumentException.class)
    public ResponseEntity<ErrorResponse> handle(IllegalArgumentException e) {
        return ResponseEntity.badRequest()
            .body(new ErrorResponse("INVALID_INPUT", e.getMessage()));
    }

    @ExceptionHandler(Exception.class)
    public ResponseEntity<ErrorResponse> handleUnexpected(Exception e) {
        log.error("Unhandled exception", e);
        return ResponseEntity.internalServerError()
            .body(new ErrorResponse("INTERNAL_ERROR", "Please try later"));
    }
}

Interview Questions