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-boun...@openjdk.java.net> On Behalf
Of Mandy Chung
Sent: Tuesday, February 12, 2019 7:32 PM
To: Roger Riggs <roger.ri...@oracle.com>
Cc: Java Core Libs <core-libs-dev@openjdk.java.net>; hotspot-runtime-
d...@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
