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

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Thu Mar 14 15:00:20 UTC 2019

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.

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?

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.

(**) 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.


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

More information about the core-libs-dev mailing list