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

[Ioi Lam]

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