Useful message about NullPointerException

[Seán Coffey]

Adding hotspot-dev to this mail thread also as it's relevant to hotspot.
(complete thread at 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-January/031015.html)

As one who often has to dig through application logs and JDK issues, I 
think this would certainly be a useful addition to the NPE handling 
process. If the VM has extra info on the exact object that caused the 
NPE, it should be output in that exception. "a.getB().getC()" is a good 
example of the different code paths one has to go down to determine 
where the NPE could have arisen from.

regards,
Sean.

On 27/01/2015 14:34, kedar mhaswade wrote:
> When the JVM executes instructions like getfield
> <http://docs.oracle.com/javase/specs/jvms/se7/html/jvms-6.html#jvms-6.5.getfield>,
> getstatic, invokevirtual etc. with *objref* on the operand stack and if
> *objref* is null, an NPE is thrown. It appears that the JVM could tell us
> more about which *objref* was null at run-time. Candidate for an RFE?
>
> That aside, (and Chris's trick is nice), but if you have no access to the
> source for the offending code, life is hard in general, isn't it? Because
> if you can't have control over the source, making that source run on a
> platform where such an RFE would be perhaps fixed (a future release of the
> JDK) would be even harder, no?
>
> On Tue, Jan 27, 2015 at 5:14 AM, Florian Weimer <fweimer at redhat.com> wrote:
>
>> On 01/21/2015 01:45 PM, pike wrote:
>>> We frequently see NullPointerException in our logs. It's really a big
>>> headache when we see a NullPointerException and it is encapsulated in
>>> another exception as we don't know which object is null and it is
>> throwing
>>> an Exception. Is there any way we can get to know the object type or the
>>> object variable name where the object is null and it is throwing a
>>> NullPointerException?
>> The line number gives you the position in the source code, and from
>> that, you can usually figure out the static type.  If this is not
>> helpful in your case, you need to say why (no debugging information?
>> multiple candidates per line?).
>>
>> The dynamic type is a different matter though, because null has no
>> specific type at run time.  It may be possible to provide type
>> information in theory, at a cost, but this would best be prototyped
>> through byte code rewriting.  Nullable annotations would also help to
>> pin-point location of the first leak, and you could record that
>> (including a stack trace) if you want something really fancy.  Whether
>> it is helpful for legacy code, I don't know.  There should be some
>> research projects out there covering this area.
>>
>> --
>> Florian Weimer / Red Hat Product Security
>>