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.
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
More information about the core-libs-dev
mailing list