Find out what variable is throwing a NullPointerEx

问题:

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

回答1:

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.

回答2:

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.

回答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.

回答4:

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.

回答5:

I think you should notice Demeters Law.

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

回答6:

Unfortunately, Java will not show you the name of the variable or the exact position of an error other than the line number. If you use Eclipse you can use nullable annotations however, see http://www.fosslc.org/drupal/content/bye-bye-npe for example. See Which @NotNull Java annotation should I use? for other annotation systems.

回答7:

What has worked really beautifully to me is catching the exception where it normally gets thrown and then using Log to see whether any of them have 'null' values.

My code:

 try {
                 if (description_visible) advice_title_cur.setText(all_title_array[pos]);
                 else advice_title_cur.setText(all_title_array[pos] + "...");

             } catch (NullPointerException e) {
                 e.printStackTrace();
                 Log.e("My name", "description_visible " + description_visible);
                 Log.e("My name", "advice_title_cur " + advice_title_cur);
                 Log.e("My name", "all_title_array " + all_title_array);
                 Log.e("My name", "pos " + pos);
             }