JEP 358 – Improved NullPointerExceptions

Programs, and Java applications are no exception, usually consist of a multitude of methods, objects, functions, annotations, and so on. In this large collection of small parts, a so-called NullPointerException (NPE) could be lurking anywhere. It’s practically impossible to locate it by hand, but thankfully the JVM can tell the developer where the problem is. It points to the exact method, filename, and even the line of code where the NPE originated. Like this, for example:

Exception in thread "main" java.lang.NullPointerException
    at Prog.main(Prog.java:5)

This error message belongs to code line a.i = 99; – but what if the code turns out to be more complicated, consisting of several variables (e.g. a.b.c.i = 99;)? Then a debugging tool is needed because most NPEs, according to Lindemaier and Schmelter, are created in production environments. The support engineer who ends up confronted with the problem is often not the developer who originally wrote the code, so for them finding the bug can be extremely difficult without additional tooling.

JEP 358 – Helpful NullPointerExceptions

The problem described above is the one JEP 358 aims to solve. By analyzing the bytecode instructions of a program, the JVM should be able to show precisely which variable returns a null. Then the JVM would output a null-detail message in the NullPointerException, which would appear alongside the usual message. It would look something like this:

Exception in thread "main" java.lang.NullPointerException: 
        Cannot assign field 'i' because 'a' is null.
    at Prog.main(Prog.java:5)

And the message for a more complex example (a.b.c.i = 99;) would appear as follows:

Exception in thread "main" java.lang.NullPointerException: 
        Cannot read field 'c' because 'a.b' is null.
    at Prog.main(Prog.java:5)

The goal of the JEP is to provide authors and developers with important and helpful information for troubleshooting. New developers would be less confused and concerned about NPEs and the general understanding of a given program could be improved.

However, the Lindemaier and Schmelter also note that this proposal would mean a null-detail message could contain variable names from the source code – which could constitute a security risk – but that leaving the names of variables out would restrict the efficacy of their suggestion.

More information about the JEP can be found in the official proposal on the OpenJDK website.