Code Advice #13: Don't spot-fix null pointer exceptions

(See intro for a background and caveats on these coding advice blog entries.) One pattern I've seen some developers use is to respond to NPE (NullPointerException) bugs by inserting a null pointer check at the location of the NPE. Frequently this will be accompanied by some sort of comment like "Why is this null?". My advice is simple: Leave the NPE until you've investigated the root cause. You need to have a null-policy. Decide which references can be null, and which can't. The problem with spot fixing an NPE is that in many cases, you've only moved the bug from one place to another. And in particular, you've moved the symptom further from the cause. First, decide whether for your own methods, you ever allow null as a return value. Instead of returning null for an empty or uninitialized list for example, always return an empty list. That doesn't mean you have to create an "unnecessary" object to indicate null; you can call Collections.emptyList(). This will return a shared object which is used for all empty lists - and through generics you still get to keep type checks: public static final List emptyList() { ... } You also need to make sure that you handle nulls properly at the boundaries of your own code. If you're calling a library, make sure that the return values are only null if your program universally allows null for the particular piece of data being passed around. If you...

Date: August, 23 2006
Url: http://blogs.sun.com/tor/entry/code_advice_13_don_t

Others News