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

[Mandy Chung]

On 3/27/19 7:18 AM, Lindenmaier, Goetz wrote:
>> , is this example very clear to them that it won't be supported?
>
> You probably meant that for
>    n().getNull().m()
> it is not printed that getNull() was called on the result of n()?

Yes, I caught my error after I sent my example.
> This is a design decision not to make the printout too complex.
>   

This is fine.   The JEP should call this out.

>
> The algorithm looks at a lot of bytecodes to print the method. I can not
> enumerate all combinations of bytecodes, it's millions. I will add a per-bytecode table to
> the "Message content" section describing what is printed for which bytecode.

This is not what I am suggesting to do.

The JEP can describe the known cases or pattern (if enumerating these 
cases is not possible) to help the readers understand the proposed 
feature and what is not covered.
> This paragraph lists a possible problem -- multiple variants of methods
> with the same name and class name -- and how this is solved.
> I added a section "Cases not covered by this JEP" and mention it there, too.

Sounds good.
>> Since the JEP quotes that NullPointerExceptions are thrown frequently
>> and swallowed, it would help if you can generate some numbers.
>> This JEP will help the discussion on the proposed feature and design and avoid
>> any
>> confusion/assumption of the implementation.
> I'll generate some numbers.  Is running jvm2008 fine?

A benchmark may not be a good representative.  I'd be interested in a 
real application
to support the claim.

OTOH, we are in agreement that this change should not incur any 
significant overhead to the construction cost of throwable.  I asked the 
data because of the claim of many NPE thrown get swallowed.


Mandy