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 <fwei...@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
