I don't see why its compilers job to manage dumb things for you, when the person writing the program should be able to do that with careful planning.
–
Neil LocketzFeb 20 '13 at 23:48

"dumb things"? this certainly isn't dumb. at least i don't think it is? i think you would need to know quite a bit about boxing/unboxing to really understand what's going on since it's all behind the scenes..
–
mreFeb 20 '13 at 23:49

I don't understand. Are you asking why the NPE happens or this is just a rant? What would be the specific answerable question?
–
madth3Feb 20 '13 at 23:59

1

@madth3, I was asking why this happened behind the scenes and why there wasn't a compiler warning (which Javier answered). No need to be sassy.
–
mreFeb 21 '13 at 0:01

6 Answers
6

I don't know what IDE are you using, but Eclipse has an option to enable warning on boxing and unboxing conversions. It is not possible to detect it as a null pointer access, since null is not immediatly unboxed, but via Bar.getId().

Nobody would be surprised about the null pointer exception. The Bar class returns a null, and a null object pointer can not be turned into a simple value. The implementation of the Bar class might be changed to initialize the id to a non-null value. This block of code can be compiled independently from the Bar class, and so assumptions about the dynamic workings of the Bar class should certainly not be coded into this block of code.

This is probably obvious, but the real solution is to use int for the id member, instead of Integer. This, then, has no issue:

i did not say the exception was unreasonable, i said it was unexpected, especially since my IDE chose to ignore it by default.
–
mreFeb 21 '13 at 0:11

OK, I was trying to get around what is "expected" and "unexpected". It is a run-time exception, not something that can be necessarily determined from static analysis. How would you expect the IDE to behave in this situation?
–
AgileProFeb 21 '13 at 0:19

I expected the IDE to at least warn me by default. Like I said, I think it's a pretty subtle runtime exception.
–
mreFeb 21 '13 at 0:21

You would expect it to determine all the situations where you might get a run time NPE? This strikes me as running up against Gödel's theorem. But I recommend avoiding the Integer class when you don't need it.
–
AgileProFeb 21 '13 at 0:25

1

Sorry about going hyperbolic, you are right. So the warning you want is simply that it is doing an inline type cast from an Integer to an int? I guess Eclipse can do that for you as a warning.
–
AgileProFeb 21 '13 at 0:31

Boxing is nothing more than syntactical sugar for casting an object like Integer to the
native equivalent 'int'. Natives can't be null but objects can. The boxing mechanism won't prevent NullPointerExceptions in these cases.

..you can largely ignore the distinction between int and Integer, with
a few caveats. An Integer expression can have a null value. If your
program tries to autounbox null, it will throw a NullPointerException.