Exceptions

// Checked exception -- must be caught or declared
public void readFile(String path) throws IOException {
    Files.readString(Path.of(path));  // IOException is checked, compiler enforces handling
}

// Unchecked exception -- no compiler enforcement
public int divide(int a, int b) {
    return a / b;  // ArithmeticException is unchecked, no throws declaration required
}

Common follow-ups: Why has the Java community increasingly moved away from checked exceptions in newer API designs, like the Streams API?;What determines whether a new custom exception class should extend Exception or RuntimeException?

// Modern try-with-resources: automatic, guaranteed cleanup
try (BufferedReader reader = new BufferedReader(new FileReader("data.txt"))) {
    String line = reader.readLine();
} catch (IOException e) {
    e.printStackTrace();
}
// reader.close() is called automatically, even if readLine() throws

// Old, verbose, error-prone equivalent
BufferedReader reader = new BufferedReader(new FileReader("data.txt"));
try {
    String line = reader.readLine();
} finally {
    reader.close();  // easy to forget, or to get wrong if this itself throws
}

Common follow-ups: What happens if the resource's close() method itself throws an exception while the try block also threw one -- which exception 'wins'?;What specific interface must a class implement to be usable in a try-with-resources statement?

public void processOrder(Order order) {
    try {
        paymentGateway.charge(order);
    } catch (IOException e) {
        // Wraps and preserves the original cause -- getCause() on OrderProcessingException returns the IOException
        throw new OrderProcessingException("Failed to process order " + order.getId(), e);
    }
}

Common follow-ups: What happens to the chained cause's information if you forget to pass it when constructing the wrapping exception?;How do logging frameworks typically render a full chain of caused-by exceptions in log output?

// Anti-pattern: overly broad catch swallows everything, including bugs
try {
    processOrder(order);
} catch (Exception e) {
    log.error("Something went wrong");  // swallows EVERYTHING, including NullPointerException bugs!
}

// Better: catch only the specific, genuinely-expected/recoverable exception
try {
    processOrder(order);
} catch (PaymentDeclinedException e) {
    notifyCustomerOfDeclinedPayment(order, e);
}

Common follow-ups: Why is catching Throwable specifically considered even more dangerous than catching Exception?;What's an appropriate strategy for a truly generic, top-level 'catch anything and log it' handler (like a global exception handler) versus this specific anti-pattern?

public class InsufficientInventoryException extends OrderException {
    private final String productId;
    private final int requested, available;

    public InsufficientInventoryException(String productId, int requested, int available) {
        super(String.format("Insufficient inventory for %s: requested %d, available %d", productId, requested, available));
        this.productId = productId;
        this.requested = requested;
        this.available = available;
    }
    // getters let calling code programmatically inspect the specific shortfall, not just read a message string
}

Common follow-ups: When does creating a new specific exception subtype provide genuine value versus becoming unnecessary proliferation?;How would you design this hierarchy to work well with a global exception handler mapping exceptions to appropriate HTTP status codes?

public int riskyMethod() {
    try {
        return 1;
    } finally {
        System.out.println("finally still runs even though try already returned!");
        // Note: a return statement HERE would actually override/discard the try block's return value --
        // a well-known finally pitfall, generally considered bad practice
    }
}

Common follow-ups: Why is returning a value from within a finally block considered a serious anti-pattern, and what confusing behavior does it cause?;How does try-with-resources' automatic close() interact with a finally block if both are present?

// A lightweight exception for a high-frequency, expected control-flow scenario
public class FastValidationException extends RuntimeException {
    public FastValidationException(String message) {
        super(message, null, false, false);  // disables both suppression AND stack trace capture
    }
}

// vs. the default, which captures a full stack trace on every single construction --
// expensive if thrown thousands of times per second in a hot path

Common follow-ups: Why is throwing exceptions for routine, expected control flow generally considered an anti-pattern in the first place, separate from the pure performance cost?;What's lost in debuggability by disabling stack trace capture, and how would you mitigate that trade-off?

try {
    riskyIOOperation();
    riskyDatabaseOperation();
} catch (IOException | SQLException e) {
    // shared handling logic for both, avoiding duplicated catch blocks
    log.error("Operation failed", e);
    throw new ServiceException("Operation failed", e);
}
// e's static type here is Exception (the nearest common supertype of IOException and SQLException)

Common follow-ups: Why does the compiler reject combining a supertype and its own subtype together in a multi-catch?;How does the caught variable's static type get determined when the combined exception types don't share an obvious common ancestor beyond Exception?

public class BatchProcessingException extends Exception {
    private final List<String> processingContext = new ArrayList<>();

    public BatchProcessingException(String message, Throwable cause) { super(message, cause); }

    public BatchProcessingException addContext(String context) {
        processingContext.add(context);
        return this;
    }
}

// Layer 1 (innermost): throws with initial context
// Layer 2: catches, adds "processing batch #47" context, rethrows the SAME exception instance
// Layer 3: catches, adds "nightly reconciliation job" context, logs full accumulated context chain

Common follow-ups: What's the trade-off of mutating and rethrowing the same exception instance versus wrapping in a new exception at each layer?;How do structured logging frameworks (like using MDC - Mapped Diagnostic Context) provide an alternative way to accumulate this same contextual information?

try {
    performRecursiveOperation();
} catch (StackOverflowError e) {  // technically legal, but generally a bad idea
    log.error("Stack overflow occurred", e);
    // The JVM's stack state at this point may be in a precarious condition;
    // "recovering" and continuing normal operation is often unreliable
}

Common follow-ups: Are there any legitimate, narrow scenarios where catching a specific Error subclass is genuinely appropriate?;How does this distinction between Error and Exception inform designing a global/top-level exception handler's scope?