It's time to gently smash your head through the wall

Input:


File file = new File("some_file_that_is_in_use_by_windows.DLL");

if(file.exists() && file.canRead() && file.canWrite())
{
   InputStream stream = new FileInputStream(file);
}

Output:


java.io.FileNotFoundException

Javadoc:
Throws:
FileNotFoundException - if the file does not exist, is a directory rather than a regular file, or for some other reason cannot be opened for reading.

::slight_smile:

FileInaccessibleException instead ???

Anything better than this… what were they thinking??

Does File#canRead return true in this case? If so, that might be an option.

canRead and canWrite (!!) return true ::slight_smile:

(updated it in the first-post)

That’s seriously messed up :slight_smile:

Is it a problem of atomicity? Is the file readable/writable but then ceases to be by the time you get to try and read from it?

* blahblahblahh is scraping the barrel here, but

Nah, the file is just in use by the OS, always.

the Exception.getMessage() tells me that this is the reason it cannot open the stream.

So not only the FileNotFoundException is misleading, also the canRead and canWrite are not reliable.

This is Java unworthy.

canRead - “Tests whether the application can read the file denoted by this abstract pathname.”

Hm… “tests”. I guess it only checks if you could theoretically read the file… as in… do I have the rights to read? (Same for canWrite.)

The javadoc isnt clear I would say. And I agree that “file not found” isnt really the most descriptive exception for this kind of thing.