Nullable Reference Types in C#: ein Vertrag zur Kompilierzeit, keine Laufzeitprüfung

Worum es geht

Die C#-Dokumentation beschreibt Nullable Reference Types als eine Gruppe von Compile-Zeit-Funktionen: einen Annotationskontext, in dem Referenztypen nicht nullable sind, sofern sie nicht mit ? geschrieben werden, sowie einen Warnkontext, in dem der Compiler eine Null-Zustandsanalyse durchführt, verfolgt, ob jeder Ausdruck not-null oder maybe-null ist, und warnt, wenn ein maybe-null-Wert dereferenziert oder einem nicht nullablen Ziel zugewiesen wird. Die Sprachreferenz macht ausdrücklich klar, dass es keinen Laufzeitunterschied gibt: string und string? sind derselbe .NET-Typ, und der Compiler fügt keine Laufzeitprüfungen hinzu. Neue Projekte setzen seit .NET 6 <Nullable>enable</Nullable>; älterer Code ist nullable-unwissend, bis die Eigenschaft oder eine #nullable enable-Direktive hinzugefügt wird. Die Analyse blickt nicht in Methodenrümpfe, daher tragen Signaturen Attribute wie [NotNullWhen(true)], [MaybeNullWhen(false)] und [MemberNotNull], um Nachbedingungen zu beschreiben, und die Dokumentation hält fest, dass die .NET-Runtime-APIs seit .NET 5 annotiert sind.

Warum es wichtig ist

Fachleute aus Kotlin, Swift und TypeScript (strictNullChecks) erwarten, dass das Typsystem Null-Sicherheit durchsetzt; in C# ist es dagegen eine Warnschicht über einem älteren Typsystem. Zwei Konsequenzen: Warnungen helfen nur, wenn sie den Build scheitern lassen, und ein nicht nullabler Parameter kann trotzdem null erhalten, über Reflection, Deserialisierung, eine nullable-unwissende Assembly oder einen Aufrufer, der ! verwendet.

So wird es angewendet

• Es projektweit aktivieren und die Nullability-Warnungen zu Fehlern hochstufen: Die Dokumentation zu den Compiler-Optionen akzeptiert nullable als Kurzform in <WarningsAsErrors>nullable</WarningsAsErrors>.
• Eine grosse Codebasis phasenweise migrieren, wie die Dokumentation beschreibt: zunächst Warnungen oder Annotationen aktivieren, oder #nullable enable Datei für Datei ergänzen, dann auf die projektweite Einstellung zusammenführen.
• An Vertrauensgrenzen trotzdem validieren: ArgumentNullException.ThrowIfNull(x) in öffentlichen APIs, und deserialisierte Objekte bis zur Prüfung als maybe-null behandeln.
• Die Attribute gegenüber ! bevorzugen: Eine TryGet-Methode mit [NotNullWhen(true)] out T? value lässt Aufrufer den Wert ohne Unterdrückung verwenden.
• Nicht nullable Member im Konstruktor initialisieren, Hilfsmethoden mit [MemberNotNull(nameof(field))] kennzeichnen, oder den Member als required deklarieren.

Stolpersteine

Die Dokumentation nennt zwei Laufzeitlücken, vor denen der Compiler nicht warnt: default bei einem Struct mit nicht nullablen Referenzfeldern, und new string[3], dessen Elemente bis zur Zuweisung null sind. Entity Framework Core liest die Annotationen, um zu entscheiden, ob eine Spalte erforderlich ist, was die Referenz als Verhaltensausnahme vermerkt. Ein uneingeschränktes generisches T? ist nicht Nullable<T>; das gilt nur, wenn T auf struct eingeschränkt ist. Der Operator ! ist ein Versprechen, keine Prüfung, und ein falsches Versprechen wird fernab seiner Ursache zu einer NullReferenceException.