Java中统一捕获所有异常时，为何仍需要finally块？

Great question! Let's break this down step by step using your code context to make it clear.

First, let's recap your scenario: You originally had a file-writing method with specific catch blocks for IndexOutOfBoundsException and IOException, plus a finally block to close the PrintWriter. Now you're wondering if replacing those specific catches with a single catch(Exception e) means you can ditch the finally and just put the close logic after the try-catch instead.

Here's your modified code snippet, cleaned up for readability:

public void writeList() {
    PrintWriter out = null;
    try {
        System.out.println("Entering try statement");
        out = new PrintWriter(new FileWriter("OutFile.txt"));
        for (int i = 0; i < SIZE; i++) {
            out.println("Value at: " + i + " = " + list.get(i));
        }
    } catch (Exception e) {
        e.printStackTrace();
    }
    // Could we move the finally code here?
    if (out != null) {
        System.out.println("Closing PrintWriter");
        out.close();
    } else {
        System.out.println("PrintWriter not open");
    }
}

The short answer is: No, moving the close logic outside the try-catch doesn't work the same way as a finally block, and here's why:

1. return statements in the try block skip external code #

Suppose you add a return at the end of your try block to exit early after a successful write:

try {
    // ... existing write code ...
    return; // Exit method right after successful write
} catch (Exception e) {
    e.printStackTrace();
}
// This close code will NEVER run if we hit that return!

A finally block, however, will execute even if the try block exits via a return statement. That's a critical guarantee for cleaning up resources like file writers.

2. catch(Exception) doesn't catch everything #

Wait, really? Yes! Exception covers all checked exceptions and most unchecked exceptions, but it does not include Error subclasses (like OutOfMemoryError, StackOverflowError, or VirtualMachineError). If an Error occurs in your try block (e.g., the JVM runs out of memory mid-write), the catch(Exception) block won't catch it, and the code after the try-catch will be skipped entirely.

A finally block, though, will execute regardless of whether an Error occurs—so your PrintWriter still gets closed properly, preventing resource leaks.

3. Exceptions in the catch block can break execution #

What if your catch block itself throws an exception? For example:

catch (Exception e) {
    e.printStackTrace();
    throw new RuntimeException("Failed to write list", e); // Re-throw a new exception
}

If you do this, the code after the try-catch will never run (the method exits when you throw the new exception). But a finally block will still execute before the method exits, ensuring your resource is cleaned up.

4. Deterministic cleanup is non-negotiable for resources #

File handles, database connections, and other resources are limited. If you don't close them reliably, you can end up with resource leaks that slow down or crash your application over time. The finally block is designed specifically to provide that reliability—its execution is guaranteed (barring a catastrophic JVM shutdown like System.exit(0)), no matter how the try/catch flow plays out.

So to sum up: Even when you catch all Exception types, a finally block is still necessary to ensure critical cleanup code runs in all scenarios. Moving that code outside the try-catch leaves you vulnerable to cases where execution skips over it, leading to resource leaks.

内容的提问来源于stack exchange，提问作者freakydavid