Find out what variable is throwing a NullPointerException programatically

Question

I know I can find out if a variable is null in Java using these techniques:

• if (var==null) -> too much work
• try { ... } catch (NullPointerException e) { ...} -> it tells me what line is throwing the exception
• using the debugger -> by hand, too slow

Consider this line of code:

if (this.superSL.items.get(name).getSource().compareTo(VIsualShoppingList.Source_EXTRA)==0)  {

I would like to know if there's a generic way to find out programatically what variable (not just the line) is throwing the NullPointerException in a certain area of code. In the example, knowing that

Answer 1

I know you suggested that (var==null) is too much work, but, as Miguel stated in the comments, that is what I would go with.

Answer 2

Since it's possible to cause a null pointer exception without even involving a variable:

throw new NullPointerException();

I would have to say that there is no generic way to pin down a null pointer exception to a specific variable.

Your best bet would be to put as few as possible statements on each line so that it becomes obvious what caused the null pointer exception. Consider refactoring your code in the question to look something like this:

List items = this.superSL.items;
String name = items.get(name);
String source = name.getSource();
if (source.compareTo(VIsualShoppingList.Source_EXTRA) == 0)  {
    // ...
}

It's more lines of code to be sure. But it's also more readable and more maintainable.

Answer 3

What do you mean by "using the debugger -> by hand, too slow"? If your code is properly structured, then there won't be more than two or three variables used on the same line. Is it so slow to check them? You don't have NullPointers every minute.

Answer 4

Sorry, no, there is not a simple programmatic way to determine which variable or method call is the source of the exception. You could use something like Aspect-Oriented Programming (AOP), e.g. AspectJ, but this is not inherent to the language and is not generally incorporated into a program simply for debugging purposes.

• if (var==null) -> too much work
• try { } catch() { }
• Debugger

I know you don't want to hear this, but these are simply the cost of doing business.

if (this.superSL.items.get(name).getSource().compareTo(VIsualShoppingList.Source_EXTRA)==0)  {

It is unusual to see so many strung together method calls. I believe you best bet is to get in the habit of breaking these up more - not necessary down to 1 call per line, but fewer than this. Why?

1) Correctness - is it valid in the design for one of these calls to return null? If so, you should break it out, test it, and handle it appropriately.

2) Understandability - it would be easier for future maintainers (including future you) to understand if you intermediate, well-named variables to help clarify what is happening on this line.

3) Efficiency - usually when you go so deep into a graph (stringing together a series of method calls), its likely you will need to go back down around there later. Capturing this intermediate value in an intermediate variable means avoiding making one or more method calls again.

4) Debugging - as indicating by your question, spltiting a complex line like this up simplifies debugging. by narrowing down the possible source of the exception.

Answer 5

I think you should notice Demeters Law.

There aren't much people following it strictly, because it results in alot of delegate methods.
But getting too far from it will result in dependencies on inner structures that should be transparent.