Java Exceptions — try-catch, throw, throws, checked vs unchecked

Exceptions are Java's mechanism for reporting that something went wrong — a missing file, a division by zero, a null where an object was expected. The compiler enforces handling for checked exceptions; unchecked ones (subclasses of RuntimeException) can be thrown and caught freely.

The exception hierarchy

Throwable
├── Error                          // JVM problems — don't catch these
│   ├── OutOfMemoryError
│   └── StackOverflowError
└── Exception                      // your problems
    ├── IOException                // checked
    ├── SQLException               // checked
    └── RuntimeException           // unchecked
        ├── NullPointerException
        ├── ArrayIndexOutOfBoundsException
        ├── ClassCastException
        └── IllegalArgumentException

try / catch / finally

try {
    doRisky();
} catch (FileNotFoundException e) {
    log.warn("missing", e);
} catch (IOException | SQLException e) {      // multi-catch — Java 7+
    log.error("IO or DB", e);
} finally {
    cleanup();                                 // always runs
}

Try-with-resources (Java 7+) — the only safe way to close things

try (var reader = Files.newBufferedReader(path)) {
    return reader.readLine();
}
// reader.close() runs automatically — even on exception

Any object implementing AutoCloseable can go in the try resource list. Multiple resources are closed in reverse order.

Checked vs unchecked

throw vs throws

// throws — declares exceptions a method can throw (checked only)
public String read(Path p) throws IOException {
    if (!Files.exists(p)) {
        // throw — actually raises an exception
        throw new IllegalArgumentException("missing: " + p);
    }
    return Files.readString(p);
}

Custom exceptions

public class OrderNotFoundException extends RuntimeException {
    private final long orderId;
    public OrderNotFoundException(long orderId) {
        super("Order not found: " + orderId);
        this.orderId = orderId;
    }
    public long orderId() { return orderId; }
}

Prefer RuntimeException for business-logic failures. Reserve checked exceptions for truly recoverable I/O errors where the caller has a meaningful choice.

Pattern matching for instanceof in catch (Java 21+)

try {
    ...
} catch (Exception e) {
    String msg = switch (e) {
        case IOException io     -> "IO: " + io.getMessage();
        case SQLException sql   -> "DB " + sql.getSQLState();
        default                 -> "unknown";
    };
}

All sub-topics

• try / catch / finally
• Try-with-resources
• throw
• throws clause
• Checked vs unchecked
• NullPointerException
• ArrayIndexOutOfBoundsException
• ClassCastException
• IllegalArgumentException
• ConcurrentModificationException
• Custom exceptions

Common mistakes

• Catching Exception or Throwable — hides Error, RuntimeException, programming bugs. Catch the narrowest type that makes sense.
• Empty catch blocks — swallows the problem. At minimum, log it.
• Using exceptions for control flow — they're ~100× slower than an if. Validate up front.
• Wrapping without the cause — throw new MyException("failed") loses the stack. Use the two-arg constructor: new MyException("failed", e).

Try it & related tools

The Java Online Compiler shows full stack traces on uncaught exceptions. For structured error payloads in APIs, the JSON to POJO tool generates error DTO classes.