Referenstyper som kan ogiltigförklaras

Artikel
01/31/2024

I en nullable-oblivious-kontext var alla referenstyper nullbara. Nullbara referenstyper refererar till en grupp funktioner som är aktiverade i en nullbar medveten kontext som minimerar sannolikheten för att koden gör att körningen genererar System.NullReferenceException. Nullbara referenstyper innehåller tre funktioner som hjälper dig att undvika dessa undantag, inklusive möjligheten att uttryckligen markera en referenstyp som nullbar:

Förbättrad analys av statiskt flöde som avgör om en variabel kan vara null innan den avrefereras.
Attribut som kommenterar API:er så att flödesanalysen avgör null-tillstånd.
Variabelanteckningar som utvecklare använder för att explicit deklarera det avsedda null-tillståndet för en variabel.

Kompilatorn spårar null-tillståndet för varje uttryck i koden vid kompileringstillfället. Null-tillståndet har ett av tre värden:

not-null: Uttrycket är känt för att vara not-null.
maybe-null: Uttrycket kan vara null.
omedveten: Kompilatorn kan inte fastställa null-tillståndet för uttrycket.

Variabelkommentarer avgör nullbarheten för en referenstypvariabel:

icke-nullbar: Om du tilldelar ett null värde eller ett kanske null-uttryck till variabeln utfärdar kompilatorn en varning. Variabler som inte är nullbara har ett standard-null-tillstånd som inte är null.
nullable: Du kan tilldela variabeln ett null värde eller ett kanske null-uttryck . När variabelns null-tillstånd kanske är null utfärdar kompilatorn en varning om du avreferera variabeln. Standardvärdet för null-tillstånd för variabeln är kanske null.
omedveten: Du kan tilldela variabeln ett null värde eller ett kanske null-uttryck . Kompilatorn utfärdar inte varningar när du avreferera variabeln eller när du tilldelar variabeln ett kanske null-uttryck .

Den omedvetna null-tillstånd och omedveten nullability matchar beteendet innan nullable referenstyper introducerades. Dessa värden är användbara under migreringen eller när din app använder ett bibliotek som inte har aktiverat nullbara referenstyper.

Null-tillståndsanalys och variabelkommentarer är inaktiverade som standard för befintliga projekt, vilket innebär att alla referenstyper fortsätter att vara nullbara. Från och med .NET 6 är de aktiverade som standard för nya projekt. Information om hur du aktiverar dessa funktioner genom att deklarera en ogiltig anteckningskontext finns i Null-kontexter.

Resten av den här artikeln beskriver hur de tre funktionsområdena fungerar för att skapa varningar när koden kanske avrefererar ett null värde. Att avreferera en variabel innebär att få åtkomst till en av dess medlemmar med hjälp av operatorn . (dot), som du ser i följande exempel:

string message = "Hello, World!";
int length = message.Length; // dereferencing "message"

När du avrefereras en variabel vars värde är nullgenererar körningen en System.NullReferenceException.

Du får lära dig mer om:

Kompilatorns null-tillståndsanalys: hur kompilatorn avgör om ett uttryck inte är null eller kanske null.
Attribut som tillämpas på API:er som ger mer kontext för kompilatorns null-tillståndsanalys.
Ogiltiga variabelanteckningar som ger information om din avsikt för variabler. Anteckningar är användbara för fält för att ange standardvärdet null-tillstånd i början av medlemsmetoderna.
Reglerna för allmänna typargument. Nya begränsningar har lagts till eftersom typparametrar kan vara referenstyper eller värdetyper. Suffixet ? implementeras på olika sätt för nullbara värdetyper och nullbara referenstyper.
Med nullbara kontexter kan du migrera stora projekt. Du kan aktivera nullbara kontexter eller varningar i delar av appen när du migrerar. När du har åtgärdat fler varningar kan du aktivera nullbara referenstyper för hela projektet.

Slutligen får du lära dig kända fallgropar för null-tillståndsanalys i struct typer och matriser.

Du kan också utforska dessa begrepp i vår Learn-modul om nullbar säkerhet i C#.

null-tillståndsanalys

När nullbara referenstyper är aktiverade spårar Null-tillståndsanalys referensernas null-tillstånd . Ett uttryck är antingen inte null eller kanske null. Kompilatorn fastställer att en variabel inte är null på två sätt:

Variabeln har tilldelats ett värde som är känt för att inte vara null.
Variabeln har kontrollerats mot null och har inte ändrats sedan den kontrollen.

När nullbara referenstyper inte är aktiverade har alla uttryck null-statusen omedveten. Resten av avsnittet beskriver beteendet när nullbara referenstyper är aktiverade.

Alla variabler som kompilatorn inte har fastställt som inte null anses vara kanske null. Analysen ger varningar i situationer där du av misstag kan avreferera ett null värde. Kompilatorn skapar varningar baserat på null-tillståndet.

När en variabel inte är null kan variabeln avrefereras på ett säkert sätt.
När en variabel kanske är null måste variabeln kontrolleras för att säkerställa att den inte null är det innan den avrefereras.

Ta följande som exempel:

string message = null;

// warning: dereference null.
Console.WriteLine($"The length of the message is {message.Length}");

var originalMessage = message;
message = "Hello, World!";

// No warning. Analysis determined "message" is not-null.
Console.WriteLine($"The length of the message is {message.Length}");

// warning!
Console.WriteLine(originalMessage.Length);

I föregående exempel avgör kompilatorn att det message kanske är null när det första meddelandet skrivs ut. Det finns ingen varning för det andra meddelandet. Den sista kodraden skapar en varning eftersom originalMessage den kan vara null. I följande exempel visas en mer praktisk användning för att korsa ett träd med noder till roten och bearbeta varje nod under bläddring:

void FindRoot(Node node, Action<Node> processNode)
{
    for (var current = node; current != null; current = current.Parent)
    {
        processNode(current);
    }
}

Den tidigare koden genererar inga varningar för att avreferera variabeln current. Statisk analys avgör att current den aldrig är avrefererad när den kanske är null. Variabeln current kontrolleras mot null innan current.Parent den används och innan den skickas current till åtgärden ProcessNode . I föregående exempel visas hur kompilatorn avgör null-tillstånd för lokala variabler när de initieras, tilldelas eller jämförs med null.

Null-tillståndsanalysen spåras inte till anropade metoder. Därför genererar fält som initieras i en vanlig hjälpmetod som anropas av alla konstruktorer en varning med följande mall:

Den icke-nullbara egenskapen "name" måste innehålla ett värde som inte är null när konstruktorn avslutas.

Du kan åtgärda dessa varningar på något av två sätt: Konstruktorlänkning eller null-attribut på hjälpmetoden. Följande kod visar ett exempel på var och en. Klassen Person använder en vanlig konstruktor som anropas av alla andra konstruktorer. Klassen Student har en hjälpmetod kommenterad med System.Diagnostics.CodeAnalysis.MemberNotNullAttribute attributet:


using System.Diagnostics.CodeAnalysis;

public class Person
{
    public string FirstName { get; set; }
    public string LastName { get; set; }

    public Person(string firstName, string lastName)
    {
        FirstName = firstName;
        LastName = lastName;
    }

    public Person() : this("John", "Doe") { }
}

public class Student : Person
{
    public string Major { get; set; }

    public Student(string firstName, string lastName, string major)
        : base(firstName, lastName)
    {
        SetMajor(major);
    }

    public Student(string firstName, string lastName) :
        base(firstName, lastName)
    {
        SetMajor();
    }

    public Student()
    {
        SetMajor();
    }

    [MemberNotNull(nameof(Major))]
    private void SetMajor(string? major = default)
    {
        Major = major ?? "Undeclared";
    }
}

Kommentar

Ett antal förbättringar av definitiv tilldelning och null-tillståndsanalys lades till i C# 10. När du uppgraderar till C# 10 kan du få färre null-varningar som är falska positiva. Du kan lära dig mer om förbättringarna i funktionsspecifikationen för definitiva tilldelningsförbättringar.

Tillståndsanalys som kan ogiltigförklaras och varningarna som kompilatorn genererar hjälper dig att undvika programfel genom att nullavreferera . Artikeln om hur du löser null-varningar innehåller tekniker för att korrigera de varningar som troligen visas i koden.

Attribut för API-signaturer

Null-tillståndsanalysen behöver tips från utvecklare för att förstå semantiken för API:er. Vissa API:er ger null-kontroller och bör ändra null-tillståndet för en variabel från kanske-null till inte-null. Andra API:er returnerar uttryck som inte är null eller kanske null beroende på null-tillståndet för indataargumenten. Tänk till exempel på följande kod som visar ett meddelande i versaler:

void PrintMessageUpper(string? message)
{
    if (!IsNull(message))
    {
        Console.WriteLine($"{DateTime.Now}: {message.ToUpper()}");
    }
}

bool IsNull(string? s) => s == null;

Baserat på inspektion anser alla utvecklare att den här koden är säker och bör inte generera varningar. Kompilatorn vet dock inte att det IsNull ger en null-kontroll och utfärdar en varning för -instruktionen message.ToUpper() , med tanke message på att det är en variabel som kanske är null . Använd attributet NotNullWhen för att åtgärda den här varningen:

bool IsNull([NotNullWhen(false)] string? s) => s == null;

Det här attributet informerar kompilatorn om att om IsNull returnerar falseär parametern s inte null. Kompilatorn ändrar null-tillståndet message för till not-null i if (!IsNull(message)) {...} blocket. Inga varningar utfärdas.

Attribut ger detaljerad information om null-tillståndet för argument, returvärden och medlemmar i objektinstansen som används för att anropa en medlem. Information om varje attribut finns i språkreferensartikeln om null-referensattribut. Från och med .NET 5 kommenteras alla .NET-körnings-API:er. Du kan förbättra den statiska analysen genom att kommentera dina API:er för att tillhandahålla semantisk information om null-tillståndet för argument och returvärden.

Ogiltiga variabelanteckningar

Null-tillståndsanalysen ger robust analys för lokala variabler. Kompilatorn behöver mer information från dig för medlemsvariabler. Kompilatorn behöver mer information för att ange null-tillståndet för alla fält inom den inledande hakparentesen för en medlem. Alla tillgängliga konstruktorer kan användas för att initiera objektet. Om ett medlemsfält någonsin kan vara inställt på måste kompilatorn anta att nulldess null-tillstånd kanske är null i början av varje metod.

Du använder anteckningar som kan deklarera om en variabel är en nullbar referenstyp eller en referenstyp som inte går att nolla. Dessa anteckningar gör viktiga instruktioner om null-tillstånd för variabler:

En referens ska inte vara null. Standardtillståndet för en icke-nullbar referensvariabel är inte null. Kompilatorn tillämpar regler som säkerställer att det är säkert att avreferera dessa variabler utan att först kontrollera att de inte är null:
- Variabeln måste initieras till ett värde som inte är null.
- Variabeln kan aldrig tilldelas värdet null. Kompilatorn utfärdar en varning när koden tilldelar ett kanske null-uttryck till en variabel som inte ska vara null.
En referens kan vara null. Standardtillståndet för en nullbar referensvariabel är kanske null. Kompilatorn tillämpar regler för att säkerställa att du söker efter en referens på rätt null sätt:
- Variabeln kan bara derefereras när kompilatorn kan garantera att värdet inte nullär .
- Dessa variabler kan initieras med standardvärdet null och kan tilldelas värdet null i annan kod.
- Kompilatorn utfärdar inte varningar när koden tilldelar ett kanske null-uttryck till en variabel som kan vara null.

Alla icke-nullbara referensvariabler har standardvärdet null-state not-null. Alla null-referensvariabler har det inledande null-tillståndetkanske-null.

En nullbar referenstyp anges med samma syntax som nullbara värdetyper: en ? läggs till i variabeltypen. Följande variabeldeklaration representerar till exempel en nullbar strängvariabel, name:

string? name;

När nullbara referenstyper är aktiverade är alla variabler där de inte läggs till i typnamnet en referenstyp som ? inte kan nollföras. Det inkluderar alla referenstypvariabler i befintlig kod när du aktiverar den här funktionen. Alla implicit inskrivna lokala variabler (deklarerade med var) är dock nullbara referenstyper. Som föregående avsnitt visade avgör statisk analys null-tillståndet för lokala variabler för att avgöra om de kanske är null innan dereferencing den.

Ibland måste du åsidosätta en varning när du vet att en variabel inte är null, men kompilatorn fastställer att dess null-tillstånd kanske är null. Du använder operatorn ! null-forgiving efter ett variabelnamn för att tvinga null-tillståndet att inte vara null. Om du till exempel vet att variabeln name inte null är det, men kompilatorn utfärdar en varning, kan du skriva följande kod för att åsidosätta kompilatorns analys:

name!.Length;

Nullbara referenstyper och nullbara värdetyper ger ett liknande semantiskt begrepp: En variabel kan representera ett värde eller objekt, eller så kan variabeln vara null. Dock implementeras nullbara referenstyper och nullbara värdetyper på olika sätt: nullbara värdetyper implementeras med hjälp av System.Nullable<T>, och nullbara referenstyper implementeras av attribut som läss av kompilatorn. Till exempel och string?string representeras båda av samma typ: System.String. int? Men och int representeras av System.Nullable<System.Int32> respektive System.Int32.

Nullbara referenstyper är en kompileringstidsfunktion. Det innebär att det är möjligt för anropare att ignorera varningar, avsiktligt använda null som argument till en metod som förväntar sig en referens som inte kan upphävas. Biblioteksförfattare bör inkludera körningskontroller mot null-argumentvärden. Är ArgumentNullException.ThrowIfNull det bästa alternativet för att kontrollera en parameter mot null vid körning.

Viktigt!

Om du aktiverar null-anteckningar kan du ändra hur Entity Framework Core avgör om en datamedlem krävs. Mer information finns i artikeln om Grunderna i Entity Framework Core: Arbeta med null-referenstyper.

Generika

Generiska objekt kräver detaljerade regler för att hantera T? för valfri typparameter T. Reglerna är nödvändigtvis detaljerade på grund av historik och den olika implementeringen för en nullbar värdetyp och en nullbar referenstyp. Nullbara värdetyper implementeras med hjälp av structen System.Nullable<T> . Nullbara referenstyper implementeras som typanteckningar som tillhandahåller semantiska regler till kompilatorn.

Om typargumentet för T är en referenstyp refererar T? till motsvarande null-referenstyp. Om till exempel T är en stringT? , så är en string?.
Om typargumentet för T är en värdetyp refererar T? till samma värdetyp, T. Till exempel, om T är en int, T? är också en int.
Om typargumentet för T är en nullbar referenstyp refererar T? till samma null-referenstyp. Om till exempel T är en string?T? , så är även en string?.
Om typargumentet för T är en nullbar värdetyp refererar T? till samma nullbara värdetyp. Om till exempel T är en int?T? , så är även en int?.

För returvärden T? motsvarar [MaybeNull]T, för argumentvärden, T? motsvarar [AllowNull]T. Mer information finns i artikeln om attribut för null-tillståndsanalys i språkreferensen.

Du kan ange olika beteende med hjälp av begränsningar:

Villkoret class innebär att det måste vara en referenstyp som T inte kan ogiltigförklaras (till exempel string). Kompilatorn skapar en varning om du använder en nullbar referenstyp, till exempel string? för T.
Villkoret class? innebär att T det måste vara en referenstyp, antingen icke-nullbar (string) eller en nullbar referenstyp (till exempel string?). När typparametern är en nullbar referenstyp, till exempel string?, ett uttryck för T? referenser som har samma null-referenstyp, till exempel string?.
Villkoret notnull innebär att det måste vara en referenstyp som T inte kan nollföras, eller en värdetyp som inte kan nulleras. Om du använder en nullbar referenstyp eller en nullbar värdetyp för typparametern skapar kompilatorn en varning. När är en värdetyp är returvärdet dessutom T den värdetypen, inte motsvarande null-värdetyp.

Dessa begränsningar hjälper till att ge kompilatorn mer information om hur T används. Det hjälper när utvecklare väljer typ för T och ger bättre null-tillståndsanalys när en instans av den generiska typen används.

Nullbara kontexter

För små projekt kan du aktivera nullbara referenstyper, åtgärda varningar och fortsätta. Men för större projekt och lösningar för flera projekt kan det generera ett stort antal varningar. Du kan använda pragmas för att aktivera nullbara referenstyper fil för fil när du börjar använda nullbara referenstyper. De nya funktionerna som skyddar mot att kasta en System.NullReferenceException kan vara störande när de aktiveras i en befintlig kodbas:

Alla uttryckligen inskrivna referensvariabler tolkas som icke-nullbara referenstyper.
Innebörden av villkoret class i generiska objekt har ändrats till en referenstyp som inte kan upphävas.
Nya varningar genereras på grund av dessa nya regler.

Den nullbara anteckningskontexten avgör kompilatorns beteende. Det finns fyra värden för den nullbara kommentarskontexten:

inaktivera: Koden är nullable-oblivious. Inaktivera matchar beteendet innan nullbara referenstyper aktiverades, förutom att den nya syntaxen genererar varningar i stället för fel.
- Nullbara varningar är inaktiverade.
- Alla referenstypvariabler är nullbara referenstyper.
- Användning av suffixet ? för att deklarera en nullbar referenstyp ger en varning.
- Du kan använda operatorn null-förlåtande, !, men den har ingen effekt.
aktivera: Kompilatorn aktiverar alla null-referensanalyser och alla språkfunktioner.
- Alla nya nullbara varningar är aktiverade.
- Du kan använda suffixet ? för att deklarera en nullbar referenstyp.
- Referenstypvariabler utan suffixet ? är icke-nullbara referenstyper.
- Operatorn null-förlåtande undertrycker varningar för en möjlig tilldelning till null.
varningar: Kompilatorn utför alla null-analyser och avger varningar när koden kan avreferera null.
- Alla nya nullbara varningar är aktiverade.
- Användning av suffixet ? för att deklarera en nullbar referenstyp ger en varning.
- Alla referenstypvariabler tillåts vara null. Medlemmar har dock null-tillståndetnot-null vid den inledande klammerparentesen för alla metoder om de inte deklareras med suffixet ? .
- Du kan använda operatorn null-förlåtande, !.
anteckningar: Kompilatorn genererar inte varningar när kod kan avreferera null, eller när du tilldelar ett uttryck som kanske är null till en variabel som inte kan upphävas.
- Alla nya nullbara varningar är inaktiverade.
- Du kan använda suffixet ? för att deklarera en nullbar referenstyp.
- Referenstypvariabler utan suffixet ? är icke-nullbara referenstyper.
- Du kan använda operatorn null-förlåtande, !, men den har ingen effekt.

Den nullbara anteckningskontexten och den nullbara varningskontexten kan anges för ett projekt med elementet <Nullable> i .csproj-filen. Det här elementet konfigurerar hur kompilatorn tolkar typernas nullbarhet och vilka varningar som genereras. I följande tabell visas de tillåtna värdena och de kontexter som de anger sammanfattas.

Kontext	Avreferensvarningar	Tilldelningsvarningar	Referenstyper	`?` Suffix	`!` Operatör
`disable`	Inaktiverat	Inaktiverat	Alla är nullbara	Skapar en varning	Har ingen effekt
`enable`	Aktiverat	Aktiverat	Ej nullbar om den inte deklareras med `?`	Deklarerar nullbar typ	Undertrycker varningar för eventuell `null` tilldelning
`warnings`	Aktiverat	Inte tillämpligt	Alla är nullbara, men medlemmar betraktas som icke-null vid inledande klammerparentes av metoder	Skapar en varning	Undertrycker varningar för eventuell `null` tilldelning
`annotations`	Inaktiverat	Inaktiverat	Ej nullbar om den inte deklareras med `?`	Deklarerar nullbar typ	Har ingen effekt

Referenstypvariabler i kod som kompilerats i en inaktiverad kontext är nullable-oblivious. Du kan tilldela en null literal- eller kanske null-variabel till en variabel som är nullable-oblivious. Standardtillståndet för en nullable-oblivious-variabel är dock inte null.

Du kan välja vilken inställning som är bäst för projektet:

Välj inaktivera för äldre projekt som du inte vill uppdatera baserat på diagnostik eller nya funktioner.
Välj varningar för att avgöra var koden kan utlösa System.NullReferenceExceptions. Du kan åtgärda dessa varningar innan du ändrar kod för att aktivera referenstyper som inte kan null-användas.
Välj anteckningar för att uttrycka din design avsikt innan du aktiverar varningar.
Välj aktivera för nya projekt och aktiva projekt där du vill skydda mot null-referensfel.

Exempel:

<Nullable>enable</Nullable>

Du kan också använda direktiv för att ange samma kontexter var som helst i källkoden. De här direktiven är mest användbara när du migrerar en stor kodbas.

#nullable enable: Anger den ogiltiga anteckningskontexten och den nullbara varningskontexten som ska aktiveras.
#nullable disable: Anger den ogiltiga kommentarskontexten och den nullbara varningskontexten som ska inaktiveras.
#nullable restore: Återställer den ogiltiga kommentarskontexten och den nullbara varningskontexten till projektinställningarna.
#nullable disable warnings: Ange den nullbara varningskontexten som ska inaktiveras.
#nullable enable warnings: Ange den nullbara varningskontexten som ska aktiveras.
#nullable restore warnings: Återställer den nullbara varningskontexten till projektinställningarna.
#nullable disable annotations: Ange den ogiltiga anteckningskontexten som ska inaktiveras.
#nullable enable annotations: Ange den nullbara anteckningskontexten som ska aktiveras.
#nullable restore annotations: Återställer kommentarsvarningskontexten till projektinställningarna.

För valfri kodrad kan du ange någon av följande kombinationer:

Varningskontext	Anteckningskontext	Använd
projektstandard	projektstandard	Standardvärde
Aktivera	disable	Åtgärda analysvarningar
Aktivera	projektstandard	Åtgärda analysvarningar
projektstandard	Aktivera	Lägga till typanteckningar
Aktivera	Aktivera	Kod som redan har migrerats
disable	Aktivera	Kommentera kod innan du åtgärdar varningar
inaktivera	disable	Lägga till äldre kod i migrerat projekt
projektstandard	disable	Sällan
disable	projektstandard	Sällan

Dessa nio kombinationer ger dig detaljerad kontroll över diagnostiken som kompilatorn genererar för din kod. Du kan aktivera fler funktioner i alla områden som du uppdaterar, utan att se fler varningar som du inte är redo att åtgärda ännu.

Viktigt!

Den globala nullbara kontexten gäller inte för genererade kodfiler. Under någon av strategierna inaktiveras den nullbara kontexten för alla källfiler som har markerats som genererade. Det innebär att alla API:er i genererade filer inte kommenteras. Det finns fyra sätt som en fil markeras som genererad:

I .editorconfig anger du generated_code = true i ett avsnitt som gäller för filen.
Placera <auto-generated> eller <auto-generated/> i en kommentar överst i filen. Det kan finnas på valfri rad i kommentaren, men kommentarsblocket måste vara det första elementet i filen.
Starta filnamnet med TemporaryGeneratedFile_
Avsluta filnamnet med .designer.cs, .generated.cs, .g.cs eller .g.i.cs.

Generatorer kan välja att använda #nullable förprocessordirektivet.

Som standard inaktiveras ogiltig anteckning och varningskontexter. Det innebär att din befintliga kod kompileras utan ändringar och utan att generera några nya varningar. Från och med .NET 6 innehåller nya projekt elementet <Nullable>enable</Nullable> i alla projektmallar.

De här alternativen innehåller två distinkta strategier för att uppdatera en befintlig kodbas för att använda null-referenstyper.

Kända fallgropar

Matriser och structs som innehåller referenstyper är kända fallgropar i nullbara referenser och den statiska analys som avgör nullsäkerhet. I båda fallen kan en referens som inte kan nulliseras initieras till null, utan att generera varningar.

Strukturer

En struct som innehåller icke-nullbara referenstyper tillåter tilldelning default för den utan varningar. Ta följande som exempel:

using System;

#nullable enable

public struct Student
{
    public string FirstName;
    public string? MiddleName;
    public string LastName;
}

public static class Program
{
    public static void PrintStudent(Student student)
    {
        Console.WriteLine($"First name: {student.FirstName.ToUpper()}");
        Console.WriteLine($"Middle name: {student.MiddleName?.ToUpper()}");
        Console.WriteLine($"Last name: {student.LastName.ToUpper()}");
    }

    public static void Main() => PrintStudent(default);
}

I föregående exempel finns det ingen varning i PrintStudent(default) medan referenstyperna FirstName som inte kan null-användas och LastName är null.

Ett annat vanligare fall är när du hanterar generiska structs. Ta följande som exempel:

#nullable enable

public struct S<T>
{
    public T Prop { get; set; }
}

public static class Program
{
    public static void Main()
    {
        string s = default(S<string>).Prop;
    }
}

I föregående exempel är null egenskapen Prop vid körning. Den tilldelas till icke-nullbar sträng utan några varningar.

Matriser

Matriser är också en känd fallgrop i nullbara referenstyper. Tänk på följande exempel som inte ger några varningar:

using System;

#nullable enable

public static class Program
{
    public static void Main()
    {
        string[] values = new string[10];
        string s = values[0];
        Console.WriteLine(s.ToUpper());
    }
}

I föregående exempel visar deklarationen för matrisen att den innehåller icke-nullbara strängar, medan dess element initieras till null. Sedan tilldelas variabeln s ett null värde (det första elementet i matrisen). Slutligen derefereras variabeln s vilket orsakar ett körningsundantag.