Non urgent question on https://bugs.openjdk.java.net/browse/JDK-4834738 (Adding which Object is null to an NPE) (original) (raw)

Ioi Lam ioi.lam at oracle.com
Tue Feb 28 01:52:39 UTC 2017

On 2/27/17 5:34 PM, David Holmes wrote:

On 28/02/2017 11:14 AM, Ioi Lam wrote:

Now sure if this has been suggested before -- how about including the BCI in the exception message. That will tell you exactly where the exception happened. In fact we can do this for any exception, not just NPEs. Like: One of the bug reports references BCIs. Not sure how useful that is to the end developer though as they typically want to map an exception to a place in the source code. It's better than nothing. I'd assume if this problem has bothered you so much to cause you to file a bug, then you would feel enough motivation to use the BCI :-)

Anyhow, the Java class simply doesn't carry enough debugging information to tell you which position of a source line triggered the exception, like

 foo.bar(x.y(), a.b);

Is it the dereference of foo, x or a?

One possibility is to update the Java class file format:

LineNumberTable_attribute { u2 attribute_name_index; u4 attribute_length; u2 line_number_table_length; { u2 start_pc; u2 line_number; } line_number_table[line_number_table_length]; }

To add a "column_number" next to the line_number. Then, the exception message could be enhanced to

java.lang.NullPointerException at Test.testNPE(Test.java:14:5) at Test.main(Test.java:8:xx)

Where "5" is the column on line 14 that triggered the exception.

Cheers, David

try { someThingSecure().someThingElseSecure().evenMoreSecure(); } catch (Security Exception e) { e.printStackTrace(); } - Ioi On 2/27/17 4:45 AM, David Holmes wrote: Hi Martijn,

On 27/02/2017 10:03 PM, Martijn Verburg wrote: Hi all,

The topic of adding more useful information to an NPE came up on the Java Champions list and after some digging we discovered some implementations elsewhere (SAP VM for example) and some historical conversations / issues. https://bugs.openjdk.java.net/browse/JDK-4834738 http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-April/013535.html

As I state in that linked topic that request was almost the inverse of other requests in this area - it wanted to report the method invoked on the null reference, whereas other requests were seeking more information on where the null arose eg in: a().b().c(); which invocation produced the NPE. But thinking about it again, perhaps reporting the member access that triggered the NPE is the most generally useful information to provide. The bug is listed as won't fix but didn't have any explanation added to it as to why. Is it just a case that the JIT and/or other mechanisms strips away that sort of information at runtime? The bug was closed as "won't fix" as part of a general cleanup up of old issues for which there are no active plans to address the issue. As I've commented in some of the issues where this was raised (and they are all quite old) there is a general lack of context available to give a meaningful error message about the NPE. Cheers, David Cheers, Martijn

More information about the hotspot-dev mailing list