Pitfall - Returning null instead of throwing an exception

suggest change

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

Feedback about page:

Feedback:
Optional: your email if you want me to get back to you:


Pitfalls - nulls and NullPointerException:
* Pitfall - Returning null instead of throwing an exception

Table Of Contents
8 Arrays
10 Maps
11 Strings
25 JAXB
29 Enums
32 Audio
41 Scanner
63 Logging
75 Lists
78 Sets
89 JAX-WS
96 XJC
98 Process
106 Modules
114 Applets
120 Pitfalls - nulls and NullPointerException
122 JNDI
139 JavaBean
141 Literals
144 Packages
150 JMX
153 JShell
159 Sockets
167 Enum Map
175 Hashtable
177 SortedMap