RFR(L): 8218628: Add detailed message to NullPointerException describing what is null.

[Mandy Chung]

I have to say that the example NPE messages this patch has
are like stuffing as much relevant information in the message
but they are not developer-friendly as Roger and David has
commented.  Exposing bytecode-level details is very confusing
to Joe's developer while, from your perspective, anything
would be useful because this is helpful for production support
purpose.  It's a tradeoff.  That's why I think the default message
should include an informative and developer-friendly message whereas
the field support needs the customization ability for better
serviceability at production environment.

Prototyping this in Java will allow us to explore other possibility
for example enabling a plugin to format a custom exception message
rather than hardcoding this in the default message.   This RFE
and JDK-8211152 may better be addressed by providing the ability
to customize the exception message format (that's the idea in
my mind but I have not had time to pursue further).

Mandy

On 2/13/19 1:09 AM, Lindenmaier, Goetz wrote:
> Hi Mandy,
> 
> Thanks for supporting my intend of adding the message as such!
> I'll start implementing this in Java and come back with a webrev
> in a while.
> 
> In parallel, I would like to continue discussing the other
> topics, e.g., the wording of the message. I will probably come up
> with a separate webrev for that.
> 
> Best regards,
>    Goetz.
> 
> 
> 
>> -----Original Message-----
>> From: core-libs-dev <core-libs-dev-bounces at openjdk.java.net> On Behalf
>> Of Mandy Chung
>> Sent: Tuesday, February 12, 2019 7:32 PM
>> To: Roger Riggs <Roger.Riggs at oracle.com>
>> Cc: Java Core Libs <core-libs-dev at openjdk.java.net>; hotspot-runtime-
>> dev at openjdk.java.net
>> Subject: Re: RFR(L): 8218628: Add detailed message to NullPointerException
>> describing what is null.
>>
>> On 2/8/19 11:46 AM, Roger Riggs wrote:
>>> Hi,
>>>
>>> A few higher level issues should be considered, though the details
>>> of the webrev captured my immediate attention.
>>>
>>> Is this the right feature and is this the right level of implementation
>>> (C++/native)?
>>> :
>>> How much of this can be done in Java code with StackWalker and other
>>> java APIs?
>>> It would be a shame to add this much native code if there was a more
>> robust
>>> way to implement it using APIs with more leverage.
>>
>> Improving the NPE message for better diagnosability is helpful while
>> I share the same concern Roger raised.
>>
>> Implementing this feature in Java and the library would be a better
>> choice as this isn't absolutely required to be done in VM in native.
>>
>> NPE keeps a backtrace capturing the method id and bci of each stack
>> frame.  One option to explore is to have StackWalker to accept a
>> Throwable object that returns a stream of StackFrame which allows
>> you to get the method and BCI and also code source (I started a
>> prototype for JDK-8189752 some time ago).  It can use the bytecode
>> library e.g. ASM to read the bytecode.  For NPE message, you can
>> implement a specialized StackFrameTraverser just for building
>> an exception message purpose.
>>
>> Mandy