Why FileNotFoundException is CheckedException?
Asked Answered
H

6

15

I know FileNotFound is Checked Exception but though it is, only during the Run time this exception will occur.It is more like Arithmetic Exception(Unchecked).

Whether it is checked or unchecked the exception will happen only during runtime.

My Question is why we call the FileNotFound/IO/DB related stuffs as Checked Exception?

Please share me your valuable thoughts :)

Heterograft answered 6/3, 2015 at 9:47 Comment(2)
` Arithmetic Exception ` is unchecked? @HeterograftMaroc
Are you implying that there are exceptions which can happen outside runtime ?Distillate
N
15

Exceptions always encountered at runtime only, Difference is made when a exception is handled.

Checked or unchecked means whether it is forced to handle at compile time or it will only be identified when it is encountered at runtime.

If an exception is checked means compiler has way to identify whether the exception can occur or not. and whenever you compile it, you will be forced to handle a checked exception and by doing this chances of runtime exceptions will be reduced.

During file handling, compiler doesn't check whether file is present or not, it just check whether you have handled fileNotFoundException or not, because once you are dealing with a file chances of encountering this exception is very high and you should handle it in your code. for arithmetic Exception there is not way to find it during compile time. and thus it is left unchecked.

Nollie answered 25/5, 2015 at 8:39 Comment(0)
P
3

All exceptions can happen only during runtime :) The difference between the Checked and Unchecked exceptions is, that the compiler is forcing you to handle the checked ones or add them to the method signature, effectively forcing the caller to do the same (handle/rethrow).

Pineda answered 25/5, 2015 at 8:31 Comment(0)
S
3

They've let it be a Checked Exception because the user can possibly "recover" from this exception by handling it. For example, the user may specify a different directory in case this exception happened.

Subtorrid answered 25/5, 2015 at 8:44 Comment(1)
I never really got this argument. Could you elaborate, please? You might want to recover from some runtime exceptions as well and still they are runtime..Pronounce
I
3

NullPointerException or ArithmeticException usually shouldn't happen in a finished, correct program. You can handle those just with checking before with if to see if you divide by 0 or an object is null and then you are sure this Exception will not be thrown. Every time handling those Exceptions can make the code less readable.

Now you could argue that you could do the same for FileNotFoundException by just checking if the file exists before doing anything. But many constructors or methods that expect a File also support String from which the file is created then. I guess it is a question of where you draw the line, if you always only have the File method and never also support String then I would have added it to the unchecked ones too I think.

In other words: if a FileNotFoundException is thrown then it can be the desired behaviour and drive the flow of your program, but NullPoinerException really shouldn't be used for that.

Infiltrate answered 25/5, 2015 at 8:48 Comment(0)
A
0

Checked Exceptions force users to explicitly handle them, they are used for 'recoverable' exceptions, where the user can handle the situation gracefully.

Let's take a FileNotFound - it is typically thrown when the file is not present and below is a related programming idiom:

FileInputStream fis = null;
try {
    fis = new FileInputStream(new File(""));
} catch (FileNotFoundException e) {
    e.printStackTrace();
} finally {
    try {
        fis.close();
    } catch (IOException e) {
        e.printStackTrace();
    }
}

The Checked Exception here forces me to declare it in a try/catch block, where I can close the fis gracefully even if there's an exception.

Now consider that FileNotFound is a runtime exception, the code hypothetically will look like below:

FileInputStream fis = null;
fis = new FileInputStream(new File(""));
fis.close();

Now if this throws a runtime exception - which you do not need to handle at compile time, your fis will not be closed gracefully and that is a resource leak.

Andris answered 13/12, 2017 at 12:19 Comment(0)
D
0

To me, it is more about whether the compiler is able to check the exception. Let's use ArithmeticException and FileNotFoundException to compare.
Let's say ArithmeticException is a checked exception. In this case, every arithmetic operation is possible to throw this exception. But how can compiler detect this? Well it is possible if all arithmetic operation are done through methods, like Interger.valueOf(1).divide(2), then if all methods are implemented with ArithmeticException, it is easy to check. However, we can have int x = 4 / 0, then it is not quite possible for compiler to detect all the codes containing arithmetic expression. That's why I think ArithmeticException is a runtime exception.
On contrast, FileNotFoundException can be checked because loading a file is achieve through specific methods, which all are implemented FileNotFoundException. Compiler can handle it well.

Dah answered 6/7, 2022 at 14:40 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.