Hi Maurizio, I put your java PoC into a webrev, and added some tests: http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/06-java-Maurizio/
Please have a look at NullPointerExceptionTestMini4.java. It is failing, as the class does not reside in a file. Do you have an idea how to fix this? Further, I extended the implementation to cover all necessary bytecodes. I had hoped it would print a message on each test case in NullPointerExceptionTest. But it seems to lose track of the byte code index at some point if the method gets bigger. I have an idea how to fix this, though, so I'm not concerned about that. I'm currently looking at how to identify hidden frames... Best regards, Goetz. > -----Original Message----- > From: Maurizio Cimadamore <maurizio.cimadam...@oracle.com> > Sent: Freitag, 15. März 2019 12:33 > To: Lindenmaier, Goetz <goetz.lindenma...@sap.com>; Mandy Chung > <mandy.ch...@oracle.com>; Roger Riggs <roger.ri...@oracle.com> > Cc: Java Core Libs <core-libs-dev@openjdk.java.net>; hotspot-runtime- > d...@openjdk.java.net > Subject: Re: RFR(L): 8218628: Add detailed message to NullPointerException > describing what is null. > > Hi Goetz, > please find the attached ASM-based patch. It is just a PoC, as such it > does not provide as fine-grained messages as the one discussed in the > RFE/JEP, but can be enhanced to cover custom debugging attribute, I believe. > > When running this: > > Object o = null; > o.toString(); > > you get: > > Exception in thread "main" java.lang.NullPointerException: attempt to > dereference 'null' when calling method 'toString' > at org.oracle.npe.NPEHandler.main(NPEHandler.java:103) > > While when running this: > > Foo foo = null; > int y = foo.x; > > You get this: > > Exception in thread "main" java.lang.NullPointerException: attempt to > dereference 'null' when accessing field 'x' > at org.oracle.npe.NPEHandler.main(NPEHandler.java:105) > > One problem I had is that ASM provides no way to get the instruction > given a program counter - which means we have to scan all the bytecodes > and update the sizes as we go along, and, ASM unfortunately doesn’t > expose opcode sizes either. A more robust solution would be to have a > big switch which returned the opcode size of any given opcode. Also, > accessing to StackWalker API on exception creation might not be > desirable in terms of performances, so this might be one of these area > where some VM help could be beneficial. Another problem is that we > cannot distinguish between user-generated exceptions (e.g. `throw new > NullPointerException`) and genuine NPE issued by the VM. > > But I guess the upshot is that it works to leave all the gory detail of > bytecode grovelling to a bytecode API - if the logic is applied lazily, > then the impact on performances should be minimal, and the solution more > maintainable longer term. > > Cheers > Maurizio > > On 15/03/2019 07:59, Lindenmaier, Goetz wrote: > > Yes, it would be nice if you shared that.
