Zeigen, wo’s weh tut

JEP 358: Verbesserte NullPointerExceptions

Dominik Mohilo

© Shutterstock / Krittin Teerawittayaart

Egal, wie gewissenhaft man sein Programm geschrieben hat, die gefürchtete NullPointerException ist praktisch jedem Entwickler schon einmal untergekommen. Die JVM weist auf den Ort des Problems hin, allerdings nicht so detailliert, wie man sich wünschen würde. Mit JEP 358 schlagen Goetz Lindemaier und Ralf Schmelter nun eine Lösung für dieses Problem vor.

Programme, und da machen auch Java-Anwendungen keine Ausnahme, bestehen in der Regel aus einer Vielzahl an Methoden, Objekten, Funktionen, Annotationen und so weiter. Und in diesem großen Sammelsurium aus Kleinteilen kann praktisch überall eine sogenannte NullPointerException (NPE) auftreten. Sie eigenhändig auszumachen ist praktisch unmöglich, doch glücklicherweise gibt es die JVM, die den Entwickler darauf hinweist, wo sie zu finden ist. Sie deutet exakt auf die Methode, den Dateinamen und sogar die Code-Zeile, in der die NPE ihren Ursprung hat. Beispielsweise so:

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

Die obige Fehlermeldung gehört zur Code-Zeile: a.i = 99; – doch was, wenn der Code sich als komplizierter herausstellt, etwa aus mehreren Variablen besteht (etwa a.b.c.i = 99;)? Dann muss ein Debugging-Tool helfen, denn die meisten NPEs entstehen, so Lindemaier und Schmelter, in Produktionsumgebungen. Der zuständige Support Engineer, der dort mit dem Problem konfrontiert ist, ist in den meisten Fällen nicht der Entwickler, der den Code ursprünglich geschrieben hat. Es wird also ohne zusätzliches Tooling extrem schwierig, den Fehler zu finden.

JEP 358 – Helpful NullPointerExceptions

Das oben beschriebene Problem soll von JEP 358 gelöst werden. Durch eine Analyse der Bytecode-Anweisungen eines Programms soll die JVM zukünftig präzise aufzeigen können, welche Variable einen Nullwert ergibt. Daraufhin soll die JVM eine null-detail message in der NullPointerException ausgeben, die neben der bislang üblichen Meldung erscheint. Das obige Beispiel würde dann wie folgt aussehen:

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

Entsprechend würde die Nachricht für das etwas komplexere Beispiel (a.b.c.i = 99;) so erscheinen:

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

Ziel des JEP 358 ist es, so die Autoren, Entwicklern wichtige und hilfreiche Informationen für die Fehlerbehebung direkt an die Hand zu geben. Neue Entwickler wären so weniger verwirrt und besorgt über NPEs und das allgemeine Verständnis eines Programms könnte so auch verbessert werden.

Weitere Informationen zum JEP gibt es im offiziellen Proposal auf der OpenJDK Homepage.

Verwandte Themen:

Geschrieben von
Dominik Mohilo
Dominik Mohilo
Dominik Mohilo studierte Germanistik und Soziologie an der Goethe-Universität in Frankfurt. Seit 2015 ist er Redakteur bei S&S-Media.
Kommentare

Hinterlasse einen Kommentar

3 Kommentare auf "JEP 358: Verbesserte NullPointerExceptions"

avatar
4000
  Subscribe  
Benachrichtige mich zu:
Anoymous
Gast

Das Ziel dieser „Verbesserung“ führt in die falsche Richtung. Tief verschachtelte Methodenaufrufe oder Attributzugriffe sind ohnehin in der Programmierung unerwünscht.
Es ist viel wichtiger die Entwickler schmerzlich bewusst zu machen auf Sorgfalt zu achten und auf null Werte vollständig zu verzichten.

Deswegen ist es schon korrekt neue Entwickler direkt beizubringen welche Regeln zu befolgen sind und derartige Pitfalls, wie im Beispiel, gar nicht erst aufkommen zu lassen bzw. direkt zu korrigieren.

TestP
Gast

Auf null kann man nicht verzichten. Denn schon etliche Klassen in der Standardbibliothek liefern sehr oft null zurück. java.util.Map ist z.B. so eine Klasse/ein Interface.

Grüße

Anoymous
Gast

Das stimmt leider, aber innerhalb der eigenen Anwendung sollte darauf verzichtet werden.
Rückgabewerte aus diesen Bibliotheken müssen dann halt auf null geprüft werden, aber innerhalb der Methode in der sie verwendet werden.
So kann man im selbst verwalteten Code ohne null Werte auskommen und den NPE bekommt man nur während der Entwicklung zu sehen, falls man irgendwo was vergessen hat.

Doch die sind schnell gefunden und behoben.