Why is FileNotFoundException CheckedException?

Question

I know that FileNotFound is a checked exception, but although it is, only at runtime will this exception happen. It is more like an arithmetic exception (unchecked).

Regardless of whether checked or unchecked, an exception will occur only at run time.

My question is why do we call FileNotFound/IO/DB related materials as checked exceptions?

Please share your valuable thoughts with me :)

Answer 1

Exceptions always occur only at runtime. The difference occurs when an exception is processed.

Checked or not checked whether it means force processing at compile time or whether it will be identified only at runtime.

If the exception is checked, then the compiler has a way to determine if an exception can occur. and whenever you compile it, you will be forced to handle the checked exception, and by doing this, the chances of the runtime exception will be reduced.

During file processing, the compiler does not check for the presence of a file or not, it just checks whether you handled fileNotFoundException or not, because as soon as you deal with a file, the probability of encountering this exception is very high, and you should handle this in your code . for arithmetic exception, there is no way to find it at compile time. and therefore it is not controlled.

Answer 2

NullPointerException or ArithmeticException usually should not occur in a ready-made, correct program. You can only handle them with a check before the if to see if you split by 0 or the null object, and then you are sure that this exception will not be thrown. Each time handling these Exceptions may make the code less readable.

Now you can argue that you can do the same for FileNotFoundException by simply checking if the file exists before doing anything. But many constructors or methods that expect File also support String , from which the file is then created. I guess this is where you draw the line, if you always have the File method and never support String , then I would add it to the unverified ones too, I think.

In other words: if a FileNotFoundException thrown, this may be the desired behavior and control the flow of your program, but NullPoinerException should not really be used for this.

Answer 3

All exceptions can occur only at runtime. The difference between Checked and Unchecked is that the compiler forces you to process the Checked tags or add them to the method signature, effectively forcing the caller to do the same (handle / rethrow).

Answer 4

They resolved this checked exception because the user can "recover" from this exception by processing it. For example, a user may specify a different directory if this exception occurs.

Answer 5

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

Take FileNotFound - it is usually thrown when the file is missing, and below is the associated 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(); } } 

Here, the checked exception forces me to declare it in a try / catch block, where I can close fis gracefully, even if there is an exception.

Now consider that FileNotFound is an exception at runtime, the code will hypothetically look like this:

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

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