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

[Ioi Lam]

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.

- Ioi


> 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
>>>>
>>