为什么java.io.File.listFiles（）抛出NPE而不是适当的异常？

Question

Today I wrote a small Java program to find files on my harddisk, partly because Windows lacks a proper one and partly because it was for fun. It simply iterates over all childs of a directory and recursively through all their children if they are directories. But then I had a NullPointerException . After some System.out.println()'s and a try-catch block I found out this happened on some directories like D:\\System Volume Information , C:\\Users\\Public\\Documents\\My Videos and C:\\ProgramData\\Templates . Windows itself says, when input in the Explorer address bar "Access denied". When exploring , they seem to be locked. The source from java.io.File tells me:

public File[] listFiles() {
    String[] ss = list();
    if (ss == null) return null; //This line seems to cause the NPE
    int n = ss.length;
    File[] fs = new File[n];
    for (int i = 0; i < n; i++) {
        fs[i] = new File(ss[i], this);
    }
    return fs;
}

My question is, why is there no proper say, IOException , SecurityException , or even an IDontCareWhatKindOfExceptionButPleaseNoNullPointerExceptionException ?

I know I can just try-catch for NPEs , or check for null , but I'm really curious of why there's no proper Exception thrown.

Since I dislike try/catch and checking for null because of the aesthetic value of code, I made some nasty, nasty reflection code (with lots of hypocritical try/catch blocks) which emulates some methods from java.io.File , since they're private, and some packages (like java.io.FileSystem ) are not visible. And because I do not care about some Windows files, I simply ignore them using this code, giving me an empty array :

public static File[] listFiles(File mThis) {
    String[] ss = list(mThis);
    if (ss == null) {
        //System.out.println("ss is null");
        return new File[] {};
    }
    int n = ss.length;
    File[] fs = new File[n];
    for (int i = 0; i < n; i++) {
        fs[i] = getNewFile(ss[i], mThis);
    }
    return fs;
}

EDIT: to avoid misinterpretations: I do use try/catch , I merely don't like them aesthetically.

EDIT2: I'd rather use a GUI than the command prompt. And I very much dislike the Windows Search GUI. It's almost painful to use.

Answer 1

Short answer:

• install JDK 7;
• use the new Files API.

You will never come back to File after that.

Answer 2

The reason why is because the designers of the API correctly identified the reason in the contract of the function (documentation + signature):

If this abstract pathname does not denote a directory, then this method returns null. Otherwise an array of File objects is returned, one for each file or directory in the directory. Pathnames denoting the directory itself and the directory's parent directory are not included in the result. Each resulting abstract pathname is constructed from this abstract pathname using the File(File, String) constructor. Therefore if this pathname is absolute then each resulting pathname is absolute; if this pathname is relative then each resulting pathname will be relative to the same directory.

It returns null and it gives the specific reason why.

Since I dislike try/catch and checking for null because of the aesthetic value of code

It may be a "short-coming" of the API but you blatantly disregarded it and as such your program crashes.