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

[Lindenmaier, Goetz]

Hi Maurizio,

> 
> I second what Mandy says.
> 
> First let me start by saying that this enhancement will be a great
> addition to our platform; back in the days when I was teaching some Java
> classes at the university, I was very aware of how hard it is to
> diagnose a NPE for someone novel to Java programming. A trained eye of
> course can quickly scan the line where an exception occurs, and quickly
> isolate the couple of problematic spots which could have caused an
> exception. But it takes time to get to that point, and having some
> helpful messages to help you to get to that point is, IMHO a valuable
> goal in itself.
Thanks!

> I also think that the design space for such an enhancement is non
> trivial, and would best be explored (and captured!) in a medium that is
> something other than a patch. What kind of improvements should we add to
> the NPE exception? What happens if the NPE already has an user-provided
> details message? Should the enhancement make use of optional debugging
> classfile attributes (you touch this in your nice RFE). And again, what
> are the performance considerations we deem important for this work to be
> declared successful? And, maintenance-wise, what is the right way to
> implement the enhancement? Should we implement that as a pure VM
> feature, should we implement it on top of the existing VM, using some
> classfile manipulation (**) ? Or a combination of those?
I'm working on a text... 

> As you can see, there are so many question this enhancement raises that
> I think going straight for a code review can be a premature move; people
> will be coming at the review table with different answers to the above
> set of questions (and maybe additional questions too :-)), and that
> could make the review process hard and frustrating for all the parties
> involved. So I warmly suggest we take a step back from the code, and
> formulate a proposal for enhancing NPE messages in Java; in this sense,
> a JEP seems to me the most natural way to move forward.
Well, I had the code around, so I started this enhancement just showing our code.
I guess a prototype is always a good starting point.

> (**) I have a quick and dirty prototype of that built using ASM which
> I'm happy to share, in case you are interested taking a look when
> evaluating alternatives.
Yes, it would be nice if you shared that.

Best regards,
  Goetz.


> 
> Cheers
> Maurizio
> 
> 
> On 14/03/2019 00:42, Mandy Chung wrote:
> > Hi Goetz,
> >
> > Roger, Coleen, Maurizio and I talked about this proposed feature.
> > We all think that improving NPE message is a useful enhancement for
> > the platform and helps developers to tell what causes NPE.
> >
> > This is not a small enhancement.  Diving into a large code review
> > would not be the best way to move this forward as you can see the
> > discussion so far.
> >
> > It would help if you can start with writing down the problem and
> > the proposal like what improvements are proposed and under what
> > circumstances may be acceptable that NPE message won't be improved.
> > This would get the discussion on the proposal feature and then
> > the discussion of the best way to to implement it in the VM, library,
> > or combination.  You can consider using the JEP template that gives
> > you a good structure to follow for the write up.
> >
> > What do you think?
> >
> > Mandy