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

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

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

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?

Cheers,
Martijn
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

David Holmes
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
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Martijn Verburg
Hi David,

Thanks for the explanation, much appreciated!

Cheers,
Martijn

On 27 February 2017 at 12:45, David Holmes <[hidden email]> 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
>>
>>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Ioi Lam
In reply to this post by David Holmes
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:

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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

David Holmes
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.

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
>>>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

David Holmes
On 28/02/2017 11:52 AM, Ioi Lam wrote:

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

Most Java developers don't even know what BCI stands for! :)

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

Hence the suggestions to report the member access that triggered the NPE
- eg:

- call to bar() on null reference
- call to y() on null reference
- access of b on null reference

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

:) Not sure how you'd carry that through to JITed code, but I like it.

Cheers,
David

> - 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
>>>>>
>>>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Volker Simonis
Hi,

as Martijn mentioned, we've implemented something like this in our SAP JVM [1].

For a the following example:

  public final NPE a() {
    return new NPE();
  }
  public final NPE b() {
    return null;
  }
  public final NPE c() {
    return new NPE();
  }
  public static void m(NPE n) {
    n.a().b().c();
  }

calling m(new NPE()) would result in the following exception:

java.lang.NullPointerException: while trying to invoke the method
NPE.c() of a null object returned from NPE.b()
        at NPE.m(NPE.java:66)
        at NPE.main(NPE.java:74)

We're considering to contribute this (and other enhancements) to the
OpenJDK - it's just a matter of resources :) Moreover, this particular
enhancement is not trivial. It requires bytecode parsing in order to
find the source of a null pointer.

The implementation also interacts with the
-XX:+/-OmitStackTraceInFastThrow option. We, in the SAP JVM, have
switched it off, so we always get the full exception message as posted
above. But that comes at the cost of more deoptimizations, because
exceptions will not be thrown right from compiled code. Oracle/OpenJDK
have switched OmitStackTraceInFastThrow on by default. This leads to
exceptions being thrown right from the JITed code (i.e. "fast throw").
But the drawback is that these are just empty, preallocated exceptions
without message and stack trace.

Regards,
Volker

[1] https://tools.hana.ondemand.com/#cloud


On Tue, Feb 28, 2017 at 2:58 AM, David Holmes <[hidden email]> wrote:

> On 28/02/2017 11:52 AM, Ioi Lam wrote:
>>
>> 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 :-)
>
>
> Most Java developers don't even know what BCI stands for! :)
>
>> 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?
>
>
> Hence the suggestions to report the member access that triggered the NPE -
> eg:
>
> - call to bar() on null reference
> - call to y() on null reference
> - access of b on null reference
>
>> 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.
>
>
> :) Not sure how you'd carry that through to JITed code, but I like it.
>
> Cheers,
> David
>
>
>> - 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
>>>>>>
>>>>
>>
>
Loading...