days
-6
0
hours
-2
-3
minutes
-2
-6
seconds
-3
-4
search
Null marks the spot

JEP 358 – Improved NullPointerExceptions

Chris Stewart
NullPointerExceptions
© Shutterstock / Krittin Teerawittayaart

No matter how carefully they wrote their program, nearly every developer knows the dreaded NullPointerException all too well. The JVM points to the location of the problem, but not in as much detail as you might like. With JEP 358, Goetz Lindemaier and Ralf Schmelter propose a solution to this problem.

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.

SEE ALSO: Quarkus – what’s next for the lightweight Java framework?

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.

    In a cloud native world enamored with microservices and serverless, meet Quarkus – Java’s brilliant response to technologies like Node.js, Python and Go that had proven quicker, smaller and arguably more nimble. Download your free beginner's tutorial written by JAX London speaker Alex Soto.

Author
Chris Stewart
Chris Stewart is an Online Editor for JAXenter.com. He studied French at Somerville College, Oxford before moving to Germany in 2011. He speaks too many languages, writes a blog, and dabbles in card tricks.

Leave a Reply

Be the First to Comment!

avatar
400
  Subscribe  
Notify of