[15] RFR: 8248476: No helpful NullPointerException message after calling fillInStackTrace

Lindenmaier, Goetz goetz.lindenmaier at sap.com
Mon Jun 29 12:07:08 UTC 2020

Hi Christoph,

When the message is computed, there is no
information about the actual parameters any more. 
I.e., I can not distinguish whether ex was null, or whether
just the stacktrace was changed.

One design principle of the new message was not 
to introduce overhead if the message is not printed. 
Therefore I don't want to record any additional 
information about what happened, which I would 
need to distinguish the cases.
Also, reporting a wrong message as the one you detected
is a no-go.
Thus, I prefer to skip the message in this case.

An alternative fix I could imagine would be to 
override fillInStackTrace in NPE.java. It could
call getMessage() and then super.fillInStackTrace, 
and return a new exception with the message.
But this would also compute the message in cases
where it is not printed.

Best regards,

> -----Original Message-----
> From: Christoph Dreis <christoph.dreis at freenet.de>
> Sent: Monday, June 29, 2020 1:28 PM
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; hotspot-runtime-
> dev at openjdk.java.net
> Subject: Re: [15] RFR: 8248476: No helpful NullPointerException message
> after calling fillInStackTrace
> Hi Goetz,
> > If changing the stack trace by calling fillInStackTrace in user code, the
> > NPE algorithm lacks the proper information to compute the message.
> > Thus, we must omit it after that call.
> > I implement this by checking for a call to fillInStackTrace at the bci
> > recorded in the exception.
> > http://cr.openjdk.java.net/~goetz/wr20/8248476-NPE_fillInStackTrace-
> jdk15/01/
> I tried this when reporting the issue already. The problem with this is, that it
> suppresses any valid exception.
> E.g. the following example would not throw any helpful NPE anymore.
> public class Main {
> 	public static void main(String[] args) {
> 		NullPointerException ex = null;
> 		ex.fillInStackTrace();
> 	}
> }
> Cheers,
> Christoph

More information about the hotspot-runtime-dev mailing list