Java Language Java Pitfalls - Nulls and NullPointerException Pitfall - Returning null instead of throwing an exception

Help us to keep this website almost Ad Free! It takes only 10 seconds of your time:
> Step 1: Go view our video on YouTube: EF Core Bulk Extensions
> Step 2: And Like the video. BONUS: You can also share it!


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>.

Got any Java Language Question?