Aus Softwarefehlern lernen – Teil 7: Der Milliarden-Dollar-Fehler

Kaum ein Softwareproblem ist so alltäglich und gleichzeitig so kostspielig wie Null-Referenzen. Sie gehören zu den am häufigsten auftretenden Ursachen für Systemabstürze, undefinierte Zustände und Sicherheitslücken. Jede Entwicklerin und jeder Entwickler hat schon einmal eine Fehlermeldung wie „NullPointerException“, „Object reference not set to an instance of an object“ oder „Segmentation fault“ gesehen.

Muster 7: Null-Referenzen und leere Werte: Der „Billion-Dollar Mistake“

Tony Hoare, einer der Väter moderner Programmiersprachen, bezeichnete die Einführung der Null-Referenz in den 1960er-Jahren später als seinen Billion-Dollar Mistake. 1965 entwickelte er die Programmiersprache ALGOL W, und um sie flexibler zu machen, erlaubte er Referenzen, die entweder auf ein Objekt zeigen oder „nichts“ bedeuten konnten. Damals erschien das praktisch: Man sparte sich komplexere Typ-Konstrukte und konnte einfach prüfen, ob ein Wert „da“ war.

Was Hoare damals nicht ahnte: Diese scheinbar harmlose Entscheidung würde in den folgenden Jahrzehnten unzählige Fehler, Sicherheitsprobleme und wirtschaftliche Schäden verursachen. Denn Null-Referenzen führen in der Praxis zu zwei typischen Mustern:

1. Fehler treten spät auf – oft erst zur Laufzeit, manchmal unter seltenen Bedingungen.
2. Die Ursache ist häufig schwer zurückzuverfolgen, weil der Nullwert meist weit entfernt von der eigentlichen Nutzung entsteht.

Im Alltag äußern sich Null-Fehler als sporadische Abstürze oder fehlerhafte Funktionen. In Unternehmenssystemen kann das bedeuten, dass einzelne Transaktionen fehlschlagen oder Daten inkonsistent werden. In kritischen Systemen können Null-Referenzen besonders ernste Folgen haben:

• Sicherheitslücken: Fehlende Null-Checks führen manchmal zu Zugriffen auf Speicherbereiche, die Angreifer ausnutzen können.
• Betriebsunterbrechungen: Webserver oder Microservices stürzen ab, weil ein Feld unerwartet null ist.
• Kaskadierende Effekte: In verteilten Systemen kann ein einziger Null-Fehler einen Dominoeffekt auslösen, wenn zum Beispiel Message Queues oder API-Aufrufe blockieren.

Besonders gefährlich sind dabei stille Null-Fehler: Wenn der Code versucht, auf ein Objekt zuzugreifen, das null ist, und die Sprache diesen Zugriff einfach ignoriert oder einen Standardwert liefert. Das kann zu Datenkorruption führen, die unter Umständen lange unentdeckt bleibt.

Die moderne Softwareentwicklung hat aus diesem Fehler gelernt. Statt überall Null-Checks zu schreiben, gilt heute:

1. Non-Null-by-Default: Viele moderne Sprachen wie Kotlin, Swift oder TypeScript setzen mit strictNullChecks den Standard auf „nicht null“. Ein Wert muss explizit als optional deklariert werden, wenn er fehlen kann.
2. Option- oder Maybe-Typen: Statt null zu verwenden, geben Funktionen zum Beispiel Option oder Maybe zurück. Der Compiler zwingt dann dazu, den Fall „kein Wert vorhanden“ explizit zu behandeln.
3. Invarianten im Konstruktor erzwingen: Objekte sollten niemals in einem halbinitialisierten Zustand existieren. Pflichtfelder werden direkt beim Erzeugen gesetzt und bleiben während der gesamten Lebensdauer gültig.
4. Explizite Domänenrepräsentation von „nicht vorhanden“: Statt einfach null zu verwenden, sollte das Fehlen eines Wertes in der Domäne abgebildet werden, zum Beispiel als NotApplicable, Unknown oder Empty.
5. Statische Analyse und Linter nutzen: Werkzeuge wie SonarQube, ESLint oder FindBugs erkennen viele Null-Risiken schon vor dem Build.

Null-Referenzen sind jedoch nicht nur ein technisches Problem, sondern auch ein mentales Muster: Sie sind oftmals der schnelle Ausweg, um etwas provisorisch zu lösen. Doch jede Null ist ein schwebender Systemzustand, der sich potenziell erst Monate später rächt. Teams, die diese Einstellung verinnerlichen, reduzieren Null-Fehler drastisch.

Tony Hoares Billion-Dollar Mistake erinnert daran, dass Designentscheidungen langfristige Kosten verursachen. Wer heute neue Software entwickelt, sollte Null-Werte konsequent vermeiden, wo immer es geht. Explizite Typen, Compiler-Checks und klare Domänenmodelle verhindern nicht nur sporadische Abstürze, sondern auch teure und schwer zu diagnostizierende Betriebsfehler.

(who)