Hey there! Let's work through your Java file I/O exception issues one by one—they're super common when you're getting started with this stuff, so you're not alone.

1. Understanding the "unreported exception IOException" Error #

First up, that initial error: error: unreported exception IOException; must be caught or declared to be thrown.

Java treats IOException (and its subclasses like FileNotFoundException) as checked exceptions. That means the language forces you to explicitly handle them in one of two ways:

• Wrap the code that might throw the exception in a try-catch block to catch and handle it, or
• Add throws IOException to the method declaration, passing the responsibility of handling the exception up to the method's caller.

2. Why You're Seeing "Where did I 'already catch' FileNotFoundException ?" #

This error almost always comes down to the order of your catch blocks. Here's the key: FileNotFoundException is a subclass of IOException. If you catch the parent class (IOException) first, the compiler knows that any FileNotFoundException would already be caught by that first block—making the subsequent catch (FileNotFoundException) block completely redundant (it would never run).

Wrong Order (Causes the Error): #

try {
    // Your file I/O code here
} catch (IOException e) {
    // Handles ALL IOExceptions, including FileNotFoundException
    e.printStackTrace();
} catch (FileNotFoundException e) {
    // This block is unreachable—compiler throws an error
    e.printStackTrace();
}

Correct Order (Fixes the Error): #

Always catch more specific exceptions (subclasses) first, then the more general parent exception:

try {
    // Your file I/O code here
} catch (FileNotFoundException e) {
    // Handles the specific "file not found" case first
    e.printStackTrace();
} catch (IOException e) {
    // Handles all other IOExceptions
    e.printStackTrace();
}

3. Simplifying finally Block Exception Handling #

You're right that adding a try-catch inside a finally block to handle IOException from closing resources feels clunky. The good news is Java 7 and later have a cleaner solution: try-with-resources.

The Clunky Traditional Approach: #

If you're using older Java versions, you do need to nest try-catch in finally when closing resources (since close() can also throw IOException):

FileInputStream fis = null;
try {
    fis = new FileInputStream("myfile.txt");
    // Read from the file
} catch (FileNotFoundException e) {
    e.printStackTrace();
} catch (IOException e) {
    e.printStackTrace();
} finally {
    if (fis != null) {
        try {
            fis.close(); // Close can throw IOExceptions, so wrap in try-catch
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
}

The Clean Try-With-Resources Approach: #

This syntax automatically closes any resources that implement AutoCloseable (which all standard I/O classes do), and handles closing exceptions behind the scenes:

try (FileInputStream fis = new FileInputStream("myfile.txt")) {
    // Read from the file—no need to manually close!
} catch (FileNotFoundException e) {
    e.printStackTrace();
} catch (IOException e) {
    e.printStackTrace();
}

No messy finally block required—Java takes care of closing the stream safely, even if an exception occurs during reading.

Quick Recap of Best Practices #

• Always handle checked exceptions (either catch them or declare throws).
• Order catch blocks from most specific to most general.
• Use try-with-resources (Java 7+) to avoid manual resource cleanup and nested try-catch in finally.

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