Jeder Javascript Programmierer ist bestimmt schon mal über den Laufzeitfehler
undefined is not a function oder auch Cannot read property ‚length‘ of null gestolpert.
Der Fehler tritt immer dann auf, wenn man mit einem Wert etwas machen möchte (z.B. als Funktion
aufrufen oder auf die length Property zugreifen), der Wert dann aber undefined oder
null ist. Auch Java oder C# Programmier kennen dieses Problem unter dem Name
NullPointerException oder NullReferenceException, und in C oder C++ gibt es das Problem
natürlich auch, hier stürzt das Programm gleich ab.
Die Idee einer speziellen null-Referenz, die überall anstelle einer „echten“ Referenz verwendet
werden kann, geht auf Tony Hoare und ALGOL in den 1960er Jahren zurück. Tony Hoare nannte seine
Erfindung in der Retrospektive den
„billion dollar mistake“,
da die dadurch entstehenden Laufzeitfehler sehr häufig die Ursache von Bugs sind und somit
hohe Kosten verursachen.
Interessanterweise haben statisch getypte, funktionale Programmiersprachen diesen „billion dollar
mistake“ nicht wiederholt. So gibt es z.B. in Haskell den Typ
Maybe, der die
Abwesenheit eines Werts explizit im Typsystem repräsentiert.
Aber auch in Sprachen wie Javascript hat man die Notwendigkeit erkannt, statisch erkennen
zu wollen, ob Werte null oder undefined sein können. So ist in
Typescript, ein statisch getypter Javascript-Dialekt,
seit einiger Zeit die strictNullChecks Option verfügbar. Wir werden in diesem Artikel sehen,
wie man mit dieser Option Laufzeitfehler vermeiden kann, welche weiteren sinnvollen Optionen
es zur Fehlervermeidung gibt, wie man die strictNullChecks Option für eine große Codebasis
inkrementell einführen kann und ob man zwischen null und undefined unterscheiden sollte.
