© Excellent backgrounds/Shutterstock.com
Kolumne: EnterpriseTales

Dem Hype hinterher?


Brauchen wir immer neue Programmiersprachen? Müssen bestehende Programmiersprachen mit immer mehr Sprachfeatures erweitert werden? Muss jedes neue Sprachfeature sofort eingesetzt werden? Welche Sprachfeatures sollten verwendet werden? Wann ist der Umstieg sinnvoll? Diese Ausgabe der Kolumne wirft einen kritischen Blick auf neue Sprachen und neue Sprachfeatures in bestehenden Sprachen.

Die Verwendung neuer Programmiersprachen ist für viele Entwickler eine interessante Abwechslung im Programmieralltag. Für ein neues Projekt wird gerne eine neue Programmiersprache verwendet, ohne sich Gedanken zu machen, ob das überhaupt sinnvoll ist. Aber warum werden neue Sprachen (oder auch Sprachfeatures in bestehenden Sprachen) überhaupt erfunden und wann ist ihr Einsatz sinnvoll?

The Billion Dollar Mistake

Tony Hoare bezeichnet sich selbst als den Erfinder der Null Reference [1] und nennt das zugleich seinen Milliarden-Dollar-Fehler (Billion Dollar Mistake); einfach deshalb, weil er der Meinung ist, diese Erfindung hätte seither verschiedene Unternehmen aufgrund von dadurch entstehenden Programmierfehlern zwischen einer und zehn Milliarden Dollar gekostet. Nach seiner Aussage hat er die Nullreferenz beim Entwurf der Programmiersprache ALGOL erfunden, einfach, weil es so leicht zu implementieren war.

Da erscheint es doch sinnvoll, beim Sprachdesign etwas besser aufzupassen. Aber was heißt denn besser aufpassen? Wie hätte man ALGOL ohne Nullreferenz besser designen können, bzw. wie kann man aus den Fehlern von damals lernen und moderne Programmiersprachen so entwickeln, dass das Problem nicht mehr auftritt?

Keine NullPointerExceptions in Kotlin?

Beim Sprachdesign von Kotlin stand geringe Fehleranfälligkeit von vornherein im Fokus. Und so wurde auch das Thema der Nullreferenz direkt adressiert. In Kotlin muss daher direkt bei der Deklaration einer Variablen angegeben werden, ob diese den Wert null annehmen kann oder nicht.

Falls eine Variable den Wert null annehmen kann, darf auch nur auf die Variable zugegriffen werden, wenn vorher überprüft wurde, ob sie nicht null ist. Versucht man es dennoch, gibt es einen Kompilierfehler. Dank geschicktem Sprachdesign sind hier NullPointerExceptions zur Laufzeit praktisch ausgeschlossen (Es gibt allerdings hier nicht näher erwähnte Spezialfälle). Darüber hinaus gibt es in Kotlin verschiedene Syntaxfeatures, um den Null-Check möglichst einfach (also mit möglichst wenig Code) durchzuführen. So kann ich mit dem Safe-Call-Operator ?. auf ein tiefer liegendes Attribut mit einem Ausdruck zugreifen, auch wenn „auf dem Weg“ irgendein Wert null ist. So liefert der Ausdruck customer?.address?.city?.zipCode im Normalfall das gewünschte Ergebnis – und null, falls eines der Zwischenergebnisse null ist (falls also z. B. die Adresse nicht gesetzt ist). Eine NullPointerException kann hier nicht entstehen.

Muss ich dann in jeder Situation, in der ich auf ein nullable Attribut zugreife, den Safe-Call-Operator verwenden? Die Antwort ist nein. Wenn ich vorher im Code einen klassischen Null-Check mache, erkennt das der Compiler und der Safe-Call-Operator ist dann nicht nötig (Listing 1). Hier liegt allerdings der Teufel im Detail. Denn während der Compiler bei der lokalen Variable in Listing 1 sicher sein kann, dass der Wert im anschließenden Block...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang