Catching java exceptions FileNotFound and IOException at the same time
Asked Answered
G

5

15

Is the FileNotFoundException somehow a "sub-exception" of the IOException?

This is my code opening an input stream to a file at the given path:

   method(){
        FileInputStream fs;
        try {
            fs = new FileInputStream(path);
            //
            fs.close();
        } catch (FileNotFoundException e) {
            e.printStackTrace();
        } catch (IOException e) {
            e.printStackTrace();
        }
    }

How come I can neglect the FileNotFound and just catch the IOException instead? Is the FNFException a part of the IOException?

Instead of catching the exceptions, what if I throw an IOException in my method?

    method() throws IOException{

        FileInputStream fs;
        fs = new FileInputStream(path);
        //
        fs.close();

    }

Can I proceed to catch a FileNotFoundException at the invoking method like this?

    try {

         method();

    }catch (FileNotFoundException e1) {}

Thanks for any help you might be able to provide!

Gallivant answered 5/3, 2014 at 11:12 Comment(0)
R
17

Is the FileNotFoundException somehow a "sub-exception" of the IOException?

Yes, FileNotFoundException extends IOException:

java.lang.Object
    java.lang.Throwable
        java.lang.Exception
            java.io.IOException
                java.io.FileNotFoundException

How come I can neglect the FileNotFound and just catch the IOException instead?

Catching a base class of the exception being thrown will catch the exception, unless there is a more specific catch clause available.

Can I proceed to catch a FileNotFoundException at the invoking method like this?

Absolutely! In fact, this is a good thing to do: your code should handle only the exceptions with which it knows how to deal, and let all other exceptions propagate to a place where it could be dealt with in a better way.

Renfrew answered 5/3, 2014 at 11:15 Comment(0)
M
4

Yes, it is.

If you look at inheritance FileNotFoundException is a sub-class of IOException. By catching the super class you also catch anything that extends it.

You can catch the more specific one first as in your first example if you need to handle it differently.

Morel answered 5/3, 2014 at 11:13 Comment(0)
I
3

From Java 7 onwards you can do:

catch(ExceptionType1 | ExceptionType2 e) to do multiple-exception catches. However, in your case, you can just catch the IOException, as you suggest.

Issuable answered 5/3, 2014 at 11:15 Comment(2)
This is true, but a red herring in this case. You don't need to catch disparate exception types when one extends the other.Heppman
Answer modified after my comment :-)Heppman
C
3

Is the FileNotFoundException somehow a "sub-exception" of the IOException?

Yes it is.

Instead of catching the exceptions, what if I throw an IOException in my method?

You can do so. When a method throws an excpetion, it can throw this exception in particular or any exception inheriting it.

Can I proceed to catch a FileNotFoundException at the invoking method like this?

Yes. If a method declares to throw A, you can catch B if B inherits A (even if B isn't thrown by A explicitly).

Side note:

  • you don't close your resources correctly;
  • if you use Java 7, use the new Files API instead.

The first point is very important. You .close() in your try block; if you can successfully open the file but fail to read from it or whatever, .close() will not be called. You should do:

FileInputStream in = ...;
try {
    // operate on "in"
} finally {
    in.close();
}

For Java 7:

try (
    FileInputStream in = ...;
) {
    // operate on "in"
}
// "in" is closed for you here
Color answered 5/3, 2014 at 11:16 Comment(0)
I
2

Yes, as the javadoc shows it, FileNotFoundException is a subclass of IOException.

If you really wantFileNotFoundException, you must catch only this execption, otherwise catching IOException will also catch any exception subclassing it, like FileNotFoundException any many others.

Inconstant answered 5/3, 2014 at 11:14 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.