java - Can I trust methods in Files will throw NoSuchFileException when expected? -

the java.nio.file.files api nice improvement on old java.io.file class, 1 detail strikes me odd; exception of delete() no methods document may throw nosuchfileexception, , delete() says optional.

i'd able differentiate between failures due missing files , other io issues, seems isn't guaranteed possible.

the alternative of calling files.exists() , beforehand risks race-condition if file created in between 2 operations.

can expect methods in files raise nosuchfileexception when appropriate? if so, documented? if not, how can safely determine failure due missing file?

---

example: on windows 7 java 7.0.02 files.readalllines() method raise nosuchfileexception, though it's not explicitly documented so:

files.readalllines(paths.get("foo"), standardcharsets.utf_8) 

java.nio.file.nosuchfileexception: foo   @ sun.nio.fs.windowsexception.translatetoioexception(windowsexception.java:79)   @ sun.nio.fs.windowsexception.rethrowasioexception(windowsexception.java:97)   @ sun.nio.fs.windowsexception.rethrowasioexception(windowsexception.java:102)   @ sun.nio.fs.windowsfilesystemprovider.newbytechannel(windowsfilesystemprovider.java:229)   @ java.nio.file.files.newbytechannel(files.java:315)   @ java.nio.file.files.newbytechannel(files.java:361)   @ java.nio.file.spi.filesystemprovider.newinputstream(filesystemprovider.java:380)   @ java.nio.file.files.newinputstream(files.java:106)   @ java.nio.file.files.newbufferedreader(files.java:2660)   @ java.nio.file.files.readalllines(files.java:2993) 

in general: no, cannot trust methods in java.nio.file.files throw nosuchfileexception when expected, can verify.

as can see stacktrace, files uses filesystemprovider perform file operations. filesystemprovider implementations restricted (like windowsfilesystemprovider) , in turn use lot of native (c) code. example, traced nosuchfileexception windowsexception relies on operating system report error_file_not_found or error_path_not_found. example newinputstream route goes channelinputstream windowschannelfactory windowsnativedispatcher.c calls native windows function createfilew.
given amount of code involved windows, not see how can trusted work same for example linux uses code here , here.

in experience, linux (posix) file system behavior pretty consistent, windows (nt) file system behavior not: not assume windows 7 behave same windows 8.

finally, remark race condition: no file system know guarantees files listed in directory exist (some files may have been deleted, when using multiple threads operating on files in same directory). using methods files.exists() beforehand is, in experience, bad idea unless allocate lot of resources (e.g. creating connection upload file). when dealing files, better assume in order , catch exceptions , try determine wrong. e.g. when reading file, open without checking if file exists, , if catch error, check if file existed start with. can save lot of i/o operations in turn performance.