Pitfall - Returning null instead of throwing an exception

Some Java programmers have a general aversion to throwing or propagating exceptions. This leads to code like the following:

public Reader getReader(String pathname) {
    try {
        return new BufferedReader(FileReader(pathname));
    } catch (IOException ex) {
        System.out.println("Open failed: " + ex.getMessage());
        return null;
    }

}

So what is the problem with that?

The problem is that the getReader is returning a null as a special value to indicate that the Reader could not be opened. Now the returned value needs to be tested to see if it is null before it is used. If the test is left out, the result will be a NullPointerException.

There are actually three problems here:

1. The IOException was caught too soon.
2. The structure of this code means that there is a risk of leaking a resource.
3. A null was used then returned because no “real” Reader was available to return.

In fact, assuming that the exception did need to be caught early like this, there were a couple of alternatives to returning null:

1. It would be possible to implement a NullReader class; e.g. one where API’s operations behaves as if the reader was already at the “end of file” position.
2. With Java 8, it would be possible to declare getReader as returning an Optional<Reader>.