Null Pointer Exception

NullPointerException is the most important exception in Java

Most of the exceptions that I've encountered during the time I've been a programmer have been NullPointerExceptions. I've never really thought that there was something wrong about it until now.

I recently watched a presentation from Infoq given by Tony Hoare called Null Reference: The Billion Dollar Mistake. In the presentation Tony Hoare talks about how he invented the null reference. The presentation got me thinking.

A NullPointerException means that there is a bug in the code. So what's wrong that this information is given as a NullPointerException? Well in my opinion the information is given too late. It should have been caught at the time of coding! The programmer shouldn't made that mistake at the first place.

I know that I'm not the only one trying to get riddof NullPointerExceptions. In Spec#, C# and Java (with help of @NotNull annotation) languages there's a way that you can define that a certain value can't be null, in Haskell there is no null.. To me these approaches seem to be too limiting - they don't really seem to be solutions as they don't give us anything to replace nulls with. But evidently they partly solve the problem by not allowing nulls.

One approach is the Null Object pattern. I think that this is an anti-pattern in most cases. Instead of having that ugly NullPointerException a program now really thinks that there is nothing wrong and handles the empty thing as it was something - This just seems to me as doing a lot of unnecesary operations for nothing. When using the Null Object pattern a programmer introduces a second emptiness that in worst case means that there has to be two checks for null value and for the new Null Object.

One interesting object that I've found (this was mentioned by someone during Hoares presentation) is Option in Scala. It forces client code to check if the value is empty or not. After that the client can safely get the value in the option-container and all the rest of the code can assume that the value is not null.

I think that the Scala approach has something to it: you should explicitly state that a value can be empty (instead of explicitly stating that a value shall not be empty).

This can't be done by returning null (null doesn't force client code to check anything). Instead return something like the Option or have another method that checks if the value is empty (and throw an exception when someone tries to get that value when it is empty).

In my opinion public method parameters should not be allowed to be null - use method overloading (if the language your working with can do that) instead and ensure that there are no null parameters. If a method can have a null parameter it either has to check for that in some part (it's really two methods) or it doesn't use the parameter at all (introduces a way to forward an ugly null to some other part of source code where the null can do more evil stuff).