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).

When the stack trace just isn't enough

When debugging I usually can find the problem simply by looking at the stack trace or by executing the test case in a debugger. Well then there's those cases when the problem isn't so simple.

Here are my tips for these situations:

1. Don't panic or give up
   
2. Make the system fail earlier
3. Testing testing testing
4. Find out the exact version where the bug was introduced to the system

Make the system fail earlier

You most likely can spot what went wrong from a stack trace (object foo was null when it shouldn't be etc.) so you can put assertions to the code that will fail (check if foo is set to null whenever someones setting foo). This can also make it simpler to reproduce the bug as there could be cases where things go wrong but from a user point of view everything is OK.

Testing testing testing

You can reveal points about a bug that are difficult to detect from code simply by testing. In my opinion testing is more objective method than diving directly to the source code (you will always look at the part of the code that you assume to be responsible of the bug --- and sometimes at least I my self will blame the wrong piece of code). For example it can be beneficial to figure out the test cases that are nearly identical to the one that reveals the bug but don't reveal it. This can dramatically narrow down the lines of code that could be responsible of the bug in question.

Shortening a test case that reveals a bug is almost always a good idea. A short test case can be executed quickly and it will focus on the components that contain the bug in question.


Find out the exact version where the bug was introduced to the system

With a quickly executable test case finding out the first version where the bug was introduced should be easy. Once the committed change that introduced the bug is known there usually is only few lines of code that could cause the bug.

This method is great as it can work also in situations where the source code is unfamiliar. Unfortunately there are situations where the method fails or doesn't help much. The bug could have been there forever, another bug in version history can get in your way, developers could have bad habits to do huge weekly / monthly commits etc..