This week's book giveaway is in the Kotlin forum.
We're giving away four copies of Kotlin in Action and have Dmitry Jemerov & Svetlana Isakova on-line!
See this thread for details.
Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Better handling of the ubiquitous NullPointerException?  RSS feed

 
Ben Ethridge
Ranch Hand
Posts: 108
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Is there a way in java to get at the variable name associated with a NullPointerException?

Over the years, I've seen these so commonly in stdout/stderr logs, but sometimes had to take educated guesses about which variable caused the exception. For example, in the following code, (with out knowing about the initial assignments at the top, obviously), I believe it would be impossible to determine which object caused the NullPointerException, since we are only given the line number to work with in the stack trace:

For the above, the stdout/stderr log produces:

java.lang.NullPointerException
at bentest.test.main(test.java:9)
null
null
class java.lang.NullPointerException
java.lang.NullPointerException


It just seems to me that java must know, at the time it threw the NullPointerException, which variable it was looking at. Doesn't it save that vital info somewhere, where we can use it?

Ben Ethridge
Integration Consultant, SCJP 1.4

[ edited to preserve formatting using the [code] and [/code] UBB tags -ds ]
[ August 11, 2004: Message edited by: Dirk Schreckmann ]
 
Ray Stojonic
Ranch Hand
Posts: 326
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
given that a NullPointException can be thrown with

throw new NullPointerException();

which gives no indication as to what was null, just that the exception occured, I'd say that no, we can't depend on any such mechanism, even if one existed. (it would be up to the other programmer to include that information)

You could add:

System.out.println( "file: " + file );
System.out.println( "o: " + o );

to your catch and easily determine the source.
[ August 10, 2004: Message edited by: Ray Stojonic ]
 
Ben Ethridge
Ranch Hand
Posts: 108
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I could, but I don't want to

Seriously, what I'm "wishing for" is another method, say, a getContents() method in the Exception class, or somewhere up the inheritance heirarchy, that behaves sort of like the toString() method.

I'm hoping that if java knows something (anything's better than nothing) about the object that caused the throw, it has some way of giving it to me. Probably a long shot, but I thought I'd ask.

Ben
 
Stefan Wagner
Ranch Hand
Posts: 1923
Linux Postgres Database Scala
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you print a StackTrace, you get the linenumber.
How many objects do you have in a line which might be null?
 
Ben Ethridge
Ranch Hand
Posts: 108
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Two, in my example above. More, in production code.

Ben
 
Eric Fletcher
Ranch Hand
Posts: 188
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Honestly that always irritated me a bit, too, but I just took it as a small cross to bear. In my experience, writing good unit tests and/or using a decent interactive debugger like the ones in Eclipse or NetBeans handle the situation nicely.

Just my two pennies...

E
 
Dirk Schreckmann
Sheriff
Posts: 7023
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In my experience, tracking down NullPointerExceptions during development is usually pretty easy, as the stack trace tends to include the offending line of code.

Note that in some situations, the compiler actually writes different variable names than the ones the programmer specified. So, the variable names used at runtime wouldn't be the same as those used in the source code.
 
Peter den Haan
author
Ranch Hand
Posts: 3252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If NullPointerException is ubiquitous in your code, you're doing something wrong. Define stronger contracts (ie be explicit about what can be returned where), enforce the contracts using JUnit tests, return empty collections and arrays rather than null values (see Josh Bloch item 27), and prefer the null object pattern over null values for collaborators.

- Peter
 
Jeroen Wenting
Ranch Hand
Posts: 5093
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
and IF something may still yield null despite all that check for it explicitly before attempting to reference it.
 
Ben Ethridge
Ranch Hand
Posts: 108
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Peter den Haan:
If NullPointerException is ubiquitous in your code, you're doing something wrong.


Then I would have to say that many, perhaps most programmers are doing something wrong with it, or perhaps the language makes it too easy to do something wrong?

The reason I say it's ubiquitous, is because it's the most common error I run across, in our company's code, in third-party code (large and small companies, whose names I won't mention here)...and in my own


Thanks for the tip about the foo.NULL, though. I had also thought about using asserts more, as perhaps a low-impact way to catch these?

Ben
 
Joel McNary
Bartender
Posts: 1840
Eclipse IDE Java Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Another thing that you can try to do (although you can only do it for your code, not third-party) is reduce the number of items on a given line that cna be null. Too many function calls on a line can greatly reduce the readability of the code, so by breaking calls onto separate line you not only increase debugability but also readability.

now, I won't say that every function call should be on its own line (although some might), but simply reducing function calls can help immensly


becomes
 
Peter den Haan
author
Ranch Hand
Posts: 3252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Ben Ethridge:
Then I would have to say that many, perhaps most programmers are doing something wrong [...]
And you might be right. Bad habits die hard. When developers join our team, one of the first things I put in their hands is Bloch's Effective Java. A recent hire - a strong developer who was used to being the senior in the team - was amazed and more than a little concerned when I started ripping the null checks out of his code in a pair session. These days, his code is less defensive code than ever, and guess what, he's seeing fewer NPEs than ever. It's not hard to do. It's not more work. It does make for clearer code. It does require a bit of discipline. It does, for some, require a bit of a culture change.

Third party code can be a problem, absolutely. I try to avoid undisciplined libraries that don't set adequate expectations and contracts. But you can't always.

- Peter
[ August 12, 2004: Message edited by: Peter den Haan ]
 
Ben Ethridge
Ranch Hand
Posts: 108
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Good input from all of you. Helped me clarify what to look for and what to do in my own code.

Thanks!

Ben
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!