Programmiersprachen: C# 8 soll Fehler mit null verhindern

Der Microsoft-Produktmanager für die Programmiersprache C#, Mads Torgersen, zeigte im Rahmen der Keynote der Konferenz DevIntersections Europe in Stockholm, die gleichzeitig die Keynote der virtuellen .NET Conf war, einen Prototyp von Version 8.0 der wichtigsten .NET-Programmiersprache C#. Um Programmierfehler zu reduzieren, will Microsoft die bisher immer möglichen null-Zuweisung zu Variablen von Referenztypen zur Ausnahme machen.

Die NullReferenceException ist ein herrschendes Problem

Seit der ersten Version von C# aus dem Jahr 2002 können Entwickler eine Variable oder einem Attribut einer Klasse, das einen Referenztyp besitzt, den Wert null zuweisen: Kunde k = null. Seit C# 2.0 ist dies auch für Wertetypen möglich, die mit Nullable<T> oder dem Fragezeichen deklariert sind: int? zahl = null.

Die Fehlerklassen NullReferenceException und ArgumentNullException
gehören zu den häufigsten Laufzeitfehlern, die .NET-Anwendung produzieren. Erstere tritt auf, wenn ein Attribut oder eine Methode auf einer Variable oder einem Attribut aufgerufen wird, das den null-Wert besitzt, wenn beispielsweise beim Aufruf k.Print(), k den Wert null hat. Eine ArgumentNullException entsteht bei der Übergabe von null an Stellen, bei denen null als Parameter nicht erlaubt ist. Diese Fehler treten in vielen .NET-basierten Anwendungen auf (auch in Microsoft Entwicklungsumgebung Visual Studio, vgl. Abb. 1) auf, wenn Entwickler den null-Fall nicht adäquat abfangen.

Um diesem Problem zu begegnen, hatte Microsoft in vergangenen C#-Versionen bereits Operatoren wie ?? (NULL-Sammeloperator in C# 3.0) und ?. (NULL-bedingte Operatoren in C# 6.0) eingeführt, die die Behandlung des null-Falls erleichtert haben.

null oder nicht null, das ist die Frage

In C# 8.0 soll es möglich sein, das Fragezeichen nicht nur bei Werttypen, sondern auch bei Referenztypen zu verwenden. Der Compiler warnt in dem Fall bei der Zuweisung eines null-Werts an einen Referenztypen, der nicht explizit mit Fragezeichen deklariert wurde, beispielsweise Kunde? k; … k = null;

Abbildung 2 zeigt die neue Warnung bei der Übergabe von null an einen Parameter vom Typ string und Abbildung 3 die Lösung, indem die Entwickler string? statt string als Parametertyp verwenden. Alternativ könnten sie mit null! statt null betonen, dass sie sich der Gefahr bewusst sind.

Auch beim Aufruf von Attributen und Methoden soll das Ausrufezeichen Warnungen des Compilers unterdrücken: k!.Print(). Das ist sinnvoll, wenn die Entwickler sich sicher sind, dass null nicht auftreten kann, zum Beispiel weil eine Hilfsroutine wie String.IsNullOrEmpty() das geprüft hat, der Compiler diese Prüfung aber nicht erkennen kann (s. Abb. 4). Microsoft nennt das Ausrufzeichen den "Dammit-Operator" (deutsch: verdammter Operator).

Datenflussanalyse

Mit Hilfe einer Datenflussanalyse soll der Compiler auch in komplexeren Szenarien mögliche null-Probleme beziehungsweise die korrekte Prüfung des null-Falls erkennen. Im Gespräch ist, dass diese Warnungen auch für Nullable Value Types eingeführt werden.

In bestehendem Programmcode wird der neuen Compiler zahlreiche Warnungen auslösen. Microsoft will daher auch erlauben, die neue null-Prüfung auszuschalten.

Details zu dem neuen Konzept der Behandlung von null-Werten findet man auf GitHub. Mads Torgersen erläutert dies auch in einem Video auf Channel9.

Über C# 7.x zu C# 8.0

Einen Erscheinungstermin für C# 8.0 hat Microsoft noch nicht bekanntgegeben. Aktuelle C# Version ist 7.1, die in Visual Studio [Update]2017[Update] Update 3 (alias Version 15.3) erschienen ist. Mit C# 7.1 hat Microsoft erstmals ein kleineres Release mit einer Versionsnummer größer 0 hinter dem Punkt veröffentlicht. Vor C# 8.0 sollen noch Versionen 7.2 und 7.3 erscheinen (s. Abb. 5).

Update 20.9. 22:30: Die Visual-Studio-Version im letzten Absatz wurde korrigiert. (rme)