Comments on: Null Creep

By: Mark Volkmann

Mark Volkmann — Fri, 09 May 2008 19:51:14 +0000

How about using annotations as described here?
http://www.mcs.vuw.ac.nz/~djp/JACK/

By: Willis Morse

Willis Morse — Wed, 30 Apr 2008 19:11:43 +0000

This NPE solution is nice and simple if your testing (unit or otherwise) can guarantee that all conditions resulting in this NPE have been tested, found and fixed before you ship.

Desktop apps have to be a lot more defensive, however. If this goes into shipping code and occurs in the field, it probably won’t get caught until some high level last defense Throwable catch block, usually at the topmost layer near the event loop. At this point, what can the app to do except quit? Yucch.

I prefer dealing with this at compile time, using the JetBrains @Nullable annotations. It forces you to deal with nulls locally at the level they occur, which is the only place you can recover from them. At that point you can then throw some semantically richer checked exception, giving the next layer up a fighting chance of figuring out what happened.

By: Bert

Bert — Tue, 29 Apr 2008 10:32:40 +0000

Actually, when the code tests for “null”, then what the code does if so should be documented somewhere in the specs…

By: Ken Keenan

Ken Keenan — Mon, 28 Apr 2008 19:21:37 +0000

I am mostly an SQL programmer but you get exactly the same thing in the database world: people allowing NULLs in database columns for no good reason.

By: Dave

Dave — Fri, 25 Apr 2008 20:56:44 +0000

I long ago wrote a NullArgumentException class (which extends IllegalArgumentException) with a static void throwIfNull(Object arg, String parameterName) method

throwIfNull(id, “id”);
throwIfNull(name, “name”);

I use a static import to get access to it.

By: Ycros

Ycros — Fri, 25 Apr 2008 14:42:38 +0000

Hell yes, throwing exceptions is what everyone should be doing – let the caller know they’re doing the wrong thing as soon as possible!

So many programmers just check for null and don’t do anything though.

By: Sam Halliday

Sam Halliday — Fri, 25 Apr 2008 09:13:45 +0000

I use a little static helper method that keeps the code clean

static public void notNull(Object… objects) {
for (Object o : objects) {
if (o == null)
throw new NullPointerException();
}
}

Just throw that off in a convenience class somewhere and reference it with static imports. Saves the dependency on Google Collections (although, admittedly I use Google Collections, but I’ve been using this since long before that library was released). The Google Collections version is arguably better for debugging (parameter names), but mine is less of a distraction at write time.

I’ve always loved the idea of @Nullable annotations… anyone know if NetBeans supports something similar? (I find NetBeans to be a much cleaner IDE, but always a year or two behind everyone else with auto hints and things like this)

http://javablog.co.uk/2007/05/07/null-parameters-and-returning-null/

By: Jesse

Jesse — Fri, 25 Apr 2008 08:18:44 +0000

Steve, you’re right about Google collections. I use it with a static import, which makes the null checks almost vanish into the code:
public Company(String id, String name) {
this.id = checkNotNull(id, “id”);
this.name = checkNotNull(name, “name”);
}

By: Steve McLeod

Steve McLeod — Fri, 25 Apr 2008 06:55:49 +0000

Great tip, my sentiment exactly. This small habit has an enormous upstream effect on code cleanliness and stability.

The same effect, but in an even nicer way can be achieved with the Preconditions class in the Google Collections.

public Company(String id, String name) {
Preconditions.checkNotNull(id);
Preconditions.checkNotNull(name);

this.id = id;
this.name = name;
}

By: Sean M.

Sean M. — Fri, 25 Apr 2008 03:09:32 +0000

Null Creep, sounds like a new Dilbert character.

Findbugs can help chase down Null Creep as well. I seem to remember Bill Pugh and the JetBrains folks having something to do with JSR-305