Useful message about NullPointerException
sean.coffey at oracle.com
Tue Jan 27 14:57:52 UTC 2015
Adding hotspot-dev to this mail thread also as it's relevant to hotspot.
(complete thread at
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.
On 27/01/2015 14:34, kedar mhaswade wrote:
> When the JVM executes instructions like 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
>>> 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
>> 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
More information about the core-libs-dev