Getting rid of Null Pointers

NullPointerException or Null Object Reference errors are so common in any Object Oriented programming languages, be it ubiquitous Java or C#, that programmers have accepted it as a 'feature'. This happens when a reference (an object handle) pointing to ‘no-where’ is called in to service a request during the execution of a program. In the traditional languages like C, it would be a memory location without any serviceable address assigned. What is worse is that, such creepy things stay unnoticed while building the executable and surface only when someone uses the ‘shipped’ program. This not only leads to the annoyance and frustration to the consumer of the program, but also reveals the ‘ability’ of the software developer to him/her. Just look at so many jokes floating around involving the software developer community.

Yesterday stayed awake till late in the night. I was trying to book a ticket at a well-known website and this is what I encountered on the screen:

java.lang.NullPointerException: null at org.apache.struts.taglib.template.InsertTag.doEndTag(InsertTag.java:133)
at booking._0002fbooking_0002fbookTicket_0002ejspbookTicket_jsp_
1._jspService
(_0002fbooking_0002fbookTicket_0002ejspbookTicket_jsp_1.java:485) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:126) at
javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.jasper.runtime.JspServlet$JspServletWrapper.service(JspServlet.
java:174) at org.apache.jasper.runtime.JspServlet.serviceJspFile(JspServlet.java:268)
at org.apache.jasper.runtime.JspServlet.service(JspServlet.java:381) at
javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at com.broadvision.servlet.ServletContainer.service(ServletContainer.java:404
) at com.broadvision.servlet.BVRequestDispatcher.forward(BVRequestDispatcher.ja
va:133) at …

While, clearly above is a testimony to a poor QA activity, but, the responsibility of the coder is no less severe either. Actually, it perhaps mirrors a poor coding practice followed by him/her which went unnoticed throughout the entire SDLC.

There is very little that a language compiler can do to check and alert the coder if he/she is leaving a dangling reference attached to 'nothing' before the code actually runs and the OS detects that the program has tried to reach a location that is either out of bounds for the current code or it is not present in the universe (mem address space) at all. Therefore, all null pointers show up only at the first usage of a handle (reference or pointer) that points to a NULL location.

If surfacing unsolicited was not enough, such ‘runtime’ exceptions generally carry useless information along to be of any help during debugging, unless the coder has implemented a meticulous audit/tracing plan. Try to decipher what went wrong in the above exception message? Here the coder at least was fortunate to have a dorky build engineer who allowed to ship the software with debug information on (look at those source code line numbers) otherwise, stack trace would have been dumber with no evidence of what went wrong and where… I mean you would not find any line numbers and if the code was subjected to massive compiler optimization then it would loose every bit of its identity due to the mangling of information and sometimes further obfuscated by dynamic compilation by JITC.

So, as they say, prevention is the best cure. Do not write code that can suffer from such an ailment and writing code as given below is suicidal. In the following example I am trying to fetch some ‘textual’ information from a Database (DB).

String txtData = getCollectionFromDB().getSomeDataForNamedKey().getValue().trim()

This looks smart (?) But, IMHO usages like this is the single biggest source of null pointers and other hypodermic bugs.

Yes, in our DB, values can be "NULL" or there may not be a matching row to fetch. Practice of in lining many calls as above is a great source of null pointer exception especially, if the data is coming from outside your code 'boundary'. Here you have absolutely no control over what is coming to you. In the above snippet, all the method calls preceding the dot (.) operator could give you a null reference leading to the exception. E.g. trim() would fail on a null value returned by getValue(); getValue() would fail on a null Object fetched by getSomeDataForNamedKey() and so on.

Why would you write code like this? This programming practice does not save anything except may be some of your typing time and finger ache! Instead of being stingy on words and lines as above, try to break calls into individual ‘statement’ and combine such statements into a code block (example shown below). This not only yields a more robust code but, also makes code easier to comprehend. Whats more, the debugger tools will also report proper line numbers happily.

Map nameValuePairMap = getCollectionFromDB();

if( isNull(nameValuePairMap) )
{
//do Blah Blah
}
else
{
NameValuePair someNameValue = nameValuePairMap.GetSomeDataForKey();
// Do Null check
...
String dataValue = someNameValue.GetValue();
if( isNull(dataValue) )
{
txtData ="";
}
else
{
txtData = dataValue.trim();
}
...
}


Follow this and & > 80% of your programming bugs (especially Null pointers) would disappear.
Ask me how do I know that :-)