null Checks

Late this afternoon I spent an enjoyable hour pair-programming for the first time in a few years with one of the programmers here. The code was new to me, and with my advancing dyslexia for other’s code I can’t say I could recount in much detail the course of the session, but it is always fascinating observing the programming practices and code idioms of an expert programmer.

Of course, there was much that I would have liked to have seen differently, but that is part of the fun. Examples of source code from great software can vary so much, who is to pronounce on the qualities of any specific code, especially in this case where the code was inherited.

Not that this will stop me from bringing up one idiom that I often see. The null check, and it seems that where there is one null check then it will not be too long before it will be joined by many, many more.

A simple Java example:

public String bobble(String str) {
    if (str == null) {
        return null;
    } else {
        return str.replaceAll(str, str);
    }
}

The value of the str parameter could be null, and as the replaceAll(…) method call on the null reference would throw an exception, then that code path is protected by a fast failing test that will return null instead.

So where does it all go wrong?

Out of the gate, null is just plain weird. Just what is null in the Java world? If Java is on OOP language, is it an object? If it’s an object what is its type? Relying on higher sources, it goes something like: The “null” literal is a representation of the single value of the null type, the null reference. Lets not even compare it to other languages, like SQL or Lisp…

Sure, so perhaps you already knew how that instanceof check worked so conveniently with null values, but my main beef is with the null contagion.

If the str value could have been null when it was passed in, then where else could it have been null? Have all those uses been checked?

What about that null I have returned out of concern for a str null; could it do damage later on?

My issue with the null check is the fear from this ticking time bomb of null references spread throughout the code, with corresponding null checks in close pursuit. Have I caught every place where that the null could turn up? If I’ve missed just one, then who can tell what that thrown NullPointerException is going to upset.

These nagging doubts really kill me.

I try to follow a walled garden strategy. Police all variables entering into the garden, not allowing the null to pass into our little realm of good reason, croquet and afternoon tea. The goal is to not have to worry about the null reference in the bulk of the code. If an external API foists one onto us, then immediately neutralize it. In turn, we shouldn’t create them out of laziness. If necessary use NullObjects. Every null check turns to steam, they all become Italian dreams.

It's only fair to share...
Share on FacebookGoogle+Tweet about this on TwitterShare on LinkedIn

Leave a Reply