null checking in the extreme

Site menu:

Topics

Recent Posts

Blog

 

October 2008
M T W T F S S
« Sep   Nov »
 12345
6789101112
13141516171819
20212223242526
2728293031  

Past Posts

Links:

null checking in the extreme

October 13th, 2008 by Jeanne Boyarsky

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 ) {
builder.append("data");
}

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.

Comments

Comment from raveman
Time October 14, 2008 at 2:43 am

When universities teach programming everything is in main() method.

Comment from raveman
Time October 14, 2008 at 2:46 am

btw. why you think that builder cant be null there? i think with AOP you can make builder to be a null, what about custom classloader? it could happen!

Comment from Dan
Time October 14, 2008 at 7:53 am

There is no way builder can be null in that example.

Comment from Robert Munteanu
Time October 14, 2008 at 8:12 am

@raveman:

Intriguing

Do you have an example?

Comment from Collin
Time October 14, 2008 at 12:24 pm

This an incorrect pattern when applied to Java. It’s a holdover from C++ where the new operator might not be able to allocate memory and so return null. In java an OutOfMemoryException is thrown. It’s impossible to return a null value from a constructor.

I grant that weird things can happen in the presence of concurrent execution but checking for null is not the proper way to solve them.

Comment from jeanne
Time October 14, 2008 at 6:30 pm

Raveman,
In “normal” programming, builder can’t be null because it was constructed. I suppose it’s possible to AOP the call away. But I don’t think adding more kludgy programming is the solution for that. It seems like it could be better handled at design time.

Comment from jeanne
Time October 14, 2008 at 6:33 pm

Collin,
I completely agree with that!

Comment from xxx
Time October 15, 2008 at 3:09 am

No, Collin, C++’s operator new really couldn’t return NULL. You’re confusing C++ with C and its malloc()

Comment from Luis Cabellos
Time October 15, 2008 at 4:23 am

No, xxx. If you disable exceptions in the C++ compiler the operator new return null pointer instead of throw a exception.

btw, I prefer the exception solution.

Comment from Collin
Time October 15, 2008 at 10:22 am

Thanks Luis and xxx for the clarification on the C++. I’ve been doing Java for so long my C++ is a little rusty.

Comment from raveman
Time October 15, 2008 at 11:33 am

package a;

public aspect ConstructorAspect {
pointcut constructorCall2(): call(StringBuilder.new(..));

StringBuilder around(): constructorCall2() {
return null;
}
}

Comment from shadytrees
Time October 15, 2008 at 12:29 pm

To be fair, anything is possible in C++. With enough template magic, you probably get a pizza delivered to your house.

Comment from jeanne
Time October 15, 2008 at 10:10 pm

Raveman,
Yuck. Not the example – it’s a good example of your point. Just that I hate to think someone would create an aspect that completely undermines how Java works.

-Jeanne

Comment from raveman
Time October 17, 2008 at 1:58 am

it could be a fun joke to do at work :D i tired it and people thought my JRE was corrupted and then they run it on their computers and also get the error :) i think its a good joke, plus it help people to realize how powerfull AOP is.

Comment from jeanne
Time October 17, 2008 at 11:40 am

Raveman,
Fun or frustrating :) That seems like a good April Fools Day thing. Although personally I’d never do it to code at work.

Comment from Tony Morris
Time November 2, 2008 at 3:24 am

This is null checking in the extreme.
http://projects.workingmouse.com/public/functionaljava/artifacts/latest/javadoc/fj/data/Option.html

Comment from jeanne
Time November 2, 2008 at 10:59 am

Tony: I like that :)

Write a comment