Jun 13 2007

NullPointerExceptions Are Not Helpful

16 Responses to “NullPointerExceptions Are Not Helpful”

1. # bhurton 13 Jun 2007 at 5:07 pm

   Null pointer exceptions are still better than what C/C++ gives you, which is segfaults. The problem is that they didn’t really solve the problem- and this is the biggest failure of Java, a failure of imagination to see the real problem and how to solve it. Generally, the error in the code isn’t where you threw the null pointer exception, the error in the code is where the value got set to null (or, more likely, didn’t get set at all). The real solution is that you need to be able to specify “nullability” as a type constraint- to be able to say that this variable or parameter can never be null.

   Of course, once you do that, a whole host of problems start arising. For example, what initial value do non-nullable values get? Obviously, they have to be given a value immediately upon allocation. How do you specify that this nullable variable is now known to be not null and can therefor be safely assign to this non-null variable? And so on. Pretty soon you start talking about a type calculus (even if you aren’t using that term), and the ML/Ocaml/Haskell programmers start wandering over.

2. # Alexon 13 Jun 2007 at 9:15 pm

   I had a cursory look at the code, and couldn’t see any obvious causes… In any case I would say it’s certainly a bug that you’re seeing an NPE rather than a more appropriate exception.

3. # CuriousGeorgeon 13 Jun 2007 at 10:32 pm

   Looks like you found a bug in Hibernate, since I doubt the Hibernate devs are intentionally throwing a NPE (or allowing one to occur). Running across bugs in libraries can be frustrating, but it’s not rare enough to be particularly noteworthy, IMHO. (Or maybe I’ve spent so much time with Maven 2 that I’m becoming jaded and starting to expect bugs. ;) ).

   Why not run your code through a debugger, place a breakpoint just before the NPE, and follow the stack trace up until you find what is null? Doesn’t seem like that’s too difficult to me. I’m sure that would take less than half the time it took you to write this blog post. Just sayin’..

4. # Roberton 14 Jun 2007 at 8:08 am

   Okay, fair enough — in my frustration, I didn’t really address why delving into the bowels of Hibernate is not an option I’m okay with.

   The fundamental problem is that this is commonplace. If this was a unique situation or an isolated occurrence, I’d be fine with it, and I’d even be willing to put some effort into improving the API (I’m doing that right now with Ruport).

   However, it’s not an isolated case. It is, in fact, the standard case whenever you try to do something non-trivial in Hibernate: you are going to get an unhelpful exception which is going to be solved only by digging into all the data and all the mapping files and all the limited documentation and then finally taking a pot-shot at something that seems kind of odd. Another example: the other day I got a LazyInstatiationexception: “no session attached to collection” (or something like that). The problem was that a the object which had the collection that could not be lazily instatiated appeared in a join table twice, so two versions of the object were getting loaded into cache, and only the first got the session. The explosion wasn’t anywhere near that point, though: it was on an attempt to initialize a collection that contained in the redundant object! That took me a long number of hours to finally debug, and I started there by digging deep into the bowels of Hibernate.

   Despite this hostility towards its users and a kind of global frustration, Hibernate has become the industry standard. So I can pretty much guaranty that I will be dealing with it as long as I’m coding Java.

   Add on top of that frustration Gavin King declaring ORM to be a solved problem, and it just made me cranky.

5. # Roberton 14 Jun 2007 at 8:21 am

   @CuriousGeorge

   Why not run your code through a debugger, place a breakpoint just before the NPE, and follow the stack trace up until you find what is null?

   That’s not the hard part. It’s more-or-less easy to figure out what is null. What’s hard is figuring out why it is null, and how to get Hibernate to make it not null. Like Brian said above: the real problem isn’t at the point where something is null, the problem is at the point where something was set to null (or not set at all).

   In my code, I spend a lot of time writing methods like this:

   
public void fooIt(final Bar barMe) {
if(barMe == null) {
throw new NullArgumentException("barMe");
}
[...]


   This is precondition/postcondition testing, so that I don’t end up with a random unhelpful NullPointerException being thrown — if a user of my code screwed up using it, they’ll know right away what the problem is and can fix it. This is being friendly to your users.

   If I weren’t to do that, I may pass barMe into another couple dozen of methods (or, worse, set it as properties in objects I return), which means that when it being null finally explodes, the user is getting a stack trace far from where the original problem actually was. This is allowing your users to plant bombs in their own code, which is not friendly.

   And when a library isn’t friendly to me, it’s exceedingly frustrating. When the library is exceedingly complicated and exceedingly frustrating, and I’m forced to try to dig into that to figure it out, it’s flat-out rude.

6. # Chui Teyon 15 Jun 2007 at 5:45 am

   Whatever happened to good old assertions that get compiled out in release mode?

7. # Roberton 15 Jun 2007 at 6:09 am

   @Chui Tey

   Or, better yet, that get left in (or at *least* logged was warnings) in release code? See Pragmatic Programmer and Release It! for a good discussions on this.

   These kinds of things never made it into Java’s culture, because its assertion functionality was very late to the party and pretty awkward to use.

8. # Roberton 18 Jun 2007 at 10:08 am

   The bug is apparently in parsing the query. The method ParserContext#getEntityPersisterByAlias is returning null when asked for the alias p (which is defined as a load-collection alias, as well as a table alias in my query). That persister is then exploding on its next use. So the surprise happens at line 174, but it explodes at either 182 or 191, depending on what the query looks like.

9. # Roberton 18 Jun 2007 at 10:12 am

   Blargh.

   ParserContext is an undocumented interface, whose implementation is being passed in.

   This is where abstraction ceases to be fun.

10. # scotton 24 Jun 2007 at 9:21 pm

    I think that’s Las Vegas debugging, technically ;)

11. # Enfranchised Mind » Some final Patternson 16 Dec 2007 at 11:26 am

    [...] This code is pretty common: T out = null; if(someTest(in)) { out = value1; } else if(someOtherTest(in)) { out = value2; } else { out = value3; } doSomethingWith(out) If you change T out = null; to just final T out;, the compiler will check that all code paths leading to “doSomethingWith(out)” will lead to “out” being assigned. And you can wipe out one more null in your code, which means one fewer opportunity for a NullPointerException to sneak out of your library and piss me off. [...]

12. # Enfranchised Mind » My Frustrations with REXML: Ruby’s Standard Library for Reading/Writing XML; or, Ruby’s Problem Is Its Type System, and Don’t Try to Tell Me Otherwiseon 24 Mar 2008 at 2:59 pm

    [...] BEEN FiXED WITH STATIC TYPING. Even more if you have a type system which can check nulls for you. Null pointers/”nil when you didn’t expect it!” errors are totally solvable problems. The fact [...]

13. # Marcon 27 Mar 2008 at 10:53 am

    I like JetBrains’ solution to the problem:

    http://www.jetbrains.com/idea/documentation/howto.html

    There’s no reason to ever get an NPE if you’re using that.

14. # Robert Fischeron 27 Mar 2008 at 11:10 am

    In this case, the NPE was coming out of Hibernate. My IDE will not fix that.

15. # Brianon 29 Mar 2008 at 9:55 am

    Also note that @nullable and @notnull are type annotations, in the sense of Ocaml or Haskell types (Ocaml calls nullable values “options”, Haskell “maybes”- same idea).

    Which means that not only should this capability (among others) be expressed in the type system, the compiler should be able to deduce whether or not a particular value is nullable or not automatically- the annotation should be optional. Again, Haskell, Ocaml, et. al. do precisely this this.

16. # Enfranchised Mind » 7 Actually Useful Things You Didn’t Know Static Typing Could Do: An Introduction for the Dynamic Language Enthusiaston 14 Apr 2008 at 7:50 am

    [...] right. If you switch to Ocaml, the compiler will guaranty that you never see a $!# NullPointerException (or equivalent) again. Ever. [...]

Leave a Reply

Name (required)

Mail (hidden) (required)

Website

Click here to receive e-mails when other comments appear on this post