Hi, I had promised to work on a better wording of the messages.
This I deliver with this webrev: http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/05-otherMessages/ The test in the webrev is modified to just print messages along with the code that raised the messages. Please have a look at these files with test output contained in the webrev: Messages with debug information: http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/05-otherMessages/output_with_debug_info.txt Messages without debug information: http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/05-otherMessages/output_no_debug_info.txt Especially look at the first few messages, they point out the usefulness of this change. They precisely say what was null in a chain of dereferences. Best regards, Goetz. > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Wednesday, February 13, 2019 10:09 AM > To: 'Mandy Chung' <mandy.ch...@oracle.com>; 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. > > 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
