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.
When universities teach programming everything is in main() method.
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!
There is no way builder can be null in that example.
@raveman:
Intriguing
Do you have an example?
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.
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.
Collin,
I completely agree with that!
No, Collin, C++’s operator new really couldn’t return NULL. You’re confusing C++ with C and its malloc()
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.
Thanks Luis and xxx for the clarification on the C++. I’ve been doing Java for so long my C++ is a little rusty.
package a;
public aspect ConstructorAspect {
pointcut constructorCall2(): call(StringBuilder.new(..));
StringBuilder around(): constructorCall2() {
return null;
}
}
To be fair, anything is possible in C++. With enough template magic, you probably get a pizza delivered to your house.
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
it could be a fun joke to do at work 😀 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.
Raveman,
Fun or frustrating 🙂 That seems like a good April Fools Day thing. Although personally I’d never do it to code at work.
This is null checking in the extreme.
http://projects.workingmouse.com/public/functionaljava/artifacts/latest/javadoc/fj/data/Option.html
Tony: I like that 🙂