Why do I need to check if a file can be read twice (once with built in File method once with Scanner-CodePudding

So I'm reviewing my professor's code for a project (my goal is to just understand everything) and she verifies that a file can be opened/read three times, and I'm not sure why all three are necessary.

1: if (!File.exists()) { } Checks if the file exists using the built in exists method on a File object

2: if (!File.canRead()){ checks if the file can be read using the built in canRead method on the File object

3 (the part I don't understand):

Scanner blank = null; 
try {
            blank = new Scanner(colorFile) ;
        } catch (FileNotFoundException e) { 
           do whatever
    }

I don't understand why if we already checked if the file can be opened using the canRead method why we need to check AGAIN if it can be opened using a Scanner.

I would appreciate any insight. Thanks.

CodePudding user response：

In this example, you are not checking a second time if the file can be opened.

In the code snippet you have provided, there is a new Scanner object made, with the object colorFile passed to it through the parentheses.

The catch section simply is error handling if the file is to not exist on the drive, it will throw an error letting you know.

CodePudding user response：

Because Scanner(File) can throw FileNotFoundException. It's part of the API, and a checked Exception. Thus, you have to catch it (or add throws to your own method). Finally, you should always close() your Scanner(s) when they wrap a File. Else you leak a file handle. The best way, in my opinion, would be try-with-resources statement.

CodePudding user response：

You understand correctly the idea behind the try/catch first you have to have an understanding of what the Exceptions are.

Basically, Exception is a special kind of object that contains information related to the abnormal behavior of the application.

Exceptions are divided into two categories:

checked;
unchecked (runtime exceptions).

Checked exceptions represent situations that are more or less expected (something could go wrong not because of some king of in your code, but because file system works this way or because database works in such way, because network connection could fail, etc). It's mandatory for your code to have a scenario for these cases. Checked exceptions are called this way because the compiler checks if they are treated or not. You have to provide a try with catch that matches the expected exception or its parent. Or as an option declare using the throws clause that method may throw an exception and then handle it downstream (as a rule of thumb remember that checked exceptions must be necessarily treated somewhere).

With regards to unchecked exceptions - these are exceptions caused by the drawbacks of code. And are represented by RuntimeException and its subclasses.

When your code tries to access a file a checked exception which is called FileNotFoundException has to be treated.

There are many things that could cause FileNotFoundException:

file-path is wrong;
file exist, but can not be accessed (due to security reasons, another process uses this file, etc);
target path exists, but it's a directory and not a file.

And even if this file was successfully accessed previously there could be some wrinkles next time. Every piece of code that deals files must threat FileNotFoundException or one of its parents like `IOException' just because a filesystem behaves this way.

Hope it answers your question.