what to do for nulls

A logical follow up to null checking in the extreme and Never return Null Arrays, is what we should be doing when a null does get returned.

The problem

Consider the following method:

public void method() {
StringBuilder builder = UnreliableCode.createBuilder();
if ( builder != null ) {

This time, a null check is appropriate because we can’t guarantee createBuilder() works as advertised.  Let’s assume that the method is either designed to return null on error or is just plain buggy.  Let’s also assume it is not owned by us so we can’t change it.

That leaves us with the question of what we should do if builder returns null. The code currently fails silently. Yuck! This means if createBuilder returns null, we just don’t append the data. Finding this bug relies on hunting it down based on the side effects. Letting Java throw the NullPointerException (or throwing our own more logical exception) based on it is preferable to failing silently. Or in this case, it might make sense to recover by creating a new StringBuilder ourselves.

Another example of handling nulls poorly is:

public void method() {
StringBuilder builder = UnreliableCode.createBuilder();
if ( builder == null ) {
System.out.println("builder is null");
} else {

Ok so we logged it.  Does that mean we don’t care and can proceed?

I once got into a debate with a former coworker about what should happen when a variable is unexpectedly null. The essence of his argument was that “code shouldn’t throw null pointers.” While this is true in some respects, it isn’t always the case. If you have a null pointer error condition, why should the code do something else to mask it?

What I think we should do

Contrary to the above, I don’t advocate throwing null pointers on purpose.  In this case, where I think it is likely to happen, I would want to handle it explicitly.  However, seeing code littered with null checks because “you never know when something might return null” seems worse to me then letting the NullPointer get thrown.  Especially if there is nothing logical to do in handling it.  When a null pointer really is unexpected is when I think it should be treated as such rather than masked.

Regardless, I think the user shouldn’t see the NullPointer or ArrayIndexOutOfBounds or any other unexpected RuntimeException.  This winds up being a matter of writing a top level handler.  For an applet/swing type app, it winds up being a matter of intercepting them to show a user message.  For a web app, it can be redirection to a custom error page.  For a command line app, it can be a text error message.  The key being that the user doesn’t care that there was a NullPointer.  He/she cares that “something went wrong.”

Never return Null Arrays!

Continuing on Jeanne’s theme of nulls, its a pet peeve of mine when I come across code that returns null arrays instead of empty arrays. The purpose of this post is to discuss some of the reasons why its a good practice to return empty arrays over null arrays, including Collection objects or typed array.

Null Pointer Exception

Consider the reusability of the following code:

public List getItems() {
   // There are no items, return null
   return null;

Let’s say you want to iterate on the results, the following code would throw a NullPointerException if used in conjunction with the code above:

List items = getItems();
for(int i=0; i<items.size(); i++) {
   // If there are no items, this code will throw a null pointer

Iterating on an array is one of the most commons practices in Java, so returning null instead of an empty array means the person is going to have to do extra null checks when they really don’t need to. In this situation, an empty array would suffice and would not produce any errors.

To summarize, it makes the code shorter, easier to read, and less likely to throw a NullPointerException. Also, there is some confusion with returning null since you may (or may not) be saying an empty array is the same thing as null. For example, the following would be confusing logic:

List items = getItems();
if(items == null) {
   // If null do one thing
} else if(items.size==0) {
   // If empty do another?

In this situation its not clear why you might act differently on the two return values and this can lead to confusing, ambiguous code.

The only time I might consider returning null valid is if there was an error of some kind, but then you should be throwing an exception (something more programmers are hesitant to do). Think of it like this, would you rather read a stack trace with a detailed error what went wrong in the code created by you, or would you rather see NullPointerException and wonder what of a dozen objects might have been null?

null checking in the extreme

In Java, we’re told to check for nulls to avoid unexpected null pointer exceptions.  This can be taken too far though.  Consider the following code:

StringBuilder builder = new StringBuilder():
if ( builder != null ) {

When did builder have the opportunity to become null? By definition, a constructor creates an object. We just called the constructor. We know builder isn’t null. Having extra code around just invites confusion. It leaves the reader of the code wondering if they are misunderstanding something. Worse , it is a form of dead code. The if statement will never be false so it serves no purpose.

When universities teach programming, they often leave out the parts about how to make code readable and easy to maintain for others. Whether that “other” is yourself in six months or someone else, it is still professional to make the code easy to maintain.

The extra null check certainly isn’t anywhere near the worst example of unmaintainable code I’ve seen. I’ll blog more examples of this in the future.