Dela via

Referenstyper som kan ogiltigförklaras

  • Artikel

Nullable-referenstyper är en grupp funktioner som minimerar sannolikheten för att koden gör att körningen genererar System.NullReferenceException. Tre egenskaper som hjälper dig att undvika dessa undantag, inklusive möjligheten att uttryckligen markera en referenstyp som nullable:

  • 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ånd har ett av två värden:

  • not-null: Uttrycket är känt för att vara not-null.
  • maybe-null: Uttrycket kan vara null.

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.

Resten av den här artikeln beskriver hur dessa tre funktionsområden fungerar för att ge varningar när din kod kan avreferera 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.

På samma sätt kan varningar skapas när [] notation används för att komma åt en medlem i ett objekt när objektet är null:

using System;

public class Collection<T>
{
    private T[] array = new T[100];
    public T this[int index]
    {
        get => array[index];
        set => array[index] = value;
    }
}

public static void Main()
{
    Collection<int> c = default;
    c[10] = 1;    // CS8602: Possible derefence of null
}

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, parametrar och returvärden för att ange standardvärdet null-state.
  • 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.
  • Den nullbara kontexten hjälper dig att migrera stora projekt. Du kan aktivera varningar och anteckningar i nullable-kontexten i delar av din app när du migrerar. När du har åtgärdat fler varningar kan du aktivera båda inställningarna 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

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

  1. Variabeln tilldelades ett värde som är känt som att vara icke-null.
  2. Variabeln kontrollerades mot null och tilldelades inte sedan den kontrollen.

Alla variabler som kompilatorn inte kan fastställa som icke-null- anses vara möjligen 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-värdekan 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 kan fält som initieras i en vanlig hjälpmetod som anropas av alla konstruktorer generera en varning med följande meddelande:

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";
    }
}

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. Diagnostiken som genereras från null-tillståndsanalysen är endast varningar.

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 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.
    • 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 den inledande null-statenot-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 ? 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. Dessutom förblir körningsbeteendet för ett program som använder nullbara annoteringar detsamma om alla nullbara annoteringar, (? och !), tas bort. Deras enda syfte är att uttrycka designsyfte och tillhandahålla information för null-tillståndsanalys.

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.

Nullbar kontext

Den nullbara kontexten avgör hur nullbara referenstypanteckningar hanteras och vilka varningar som genereras av statisk nulltillståndsanalys. Den nullbara kontexten innehåller två flaggor: anteckningsinställningen och varningsinställningen .

Både -kommentaren och varning inställningar är inaktiverade som standard för befintliga projekt. Från och med .NET 6 (C# 10) aktiveras båda flaggorna som standard för nya projekt. Anledningen till två distinkta flaggor för den nullbara kontexten är att göra det enklare att migrera stora projekt som föregå införandet av nullbara referenstyper.

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 kombinationer för null-kontext inställningar:

  • båda inaktiverade: 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.
  • båda aktiverade: 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 utelämnar varningar för en eventuell avreferering av null.
  • varning aktiverad: Kompilatorn utför alla null-analyser och avger varningar när kod 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, !.
  • kommentarer aktiverade: Kompilatorn genererar inte varningar när koden kan komma att avreferera nulleller när du tilldelar ett uttryck som kan vara null till en variabel som inte tillåter null.
    • 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 flaggor var som helst i källkoden. De här direktiven är mest användbara när du migrerar en stor kodbas.

  • #nullable enable: Anger antecknings- och varningsflaggor till aktivera.
  • #nullable disable: Anger antecknings- och varningsflaggor till inaktivera.
  • #nullable restore: Återställer anteckningsflaggan och varningsflaggan till projektinställningarna.
  • #nullable disable warnings: Ställ in varningsflaggan på inaktivera.
  • #nullable enable warnings: Ställ in varningsflaggan på aktivera.
  • #nullable restore warnings: Återställer varningsflaggan till projektinställningarna.
  • #nullable disable annotations: Ställ in anteckningsflaggan på inaktivera.
  • #nullable enable annotations: Ställ in anteckningsflaggan på aktivera.
  • #nullable restore annotations: Återställer anteckningsflaggan till projektinställningarna.

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

Varningsflagga Anteckningsflagga 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
disable 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. Inga nullable-varningar skapas för genererade filer. Det finns fyra sätt som en fil markeras som genererad:

  1. I .editorconfig anger du generated_code = true i ett avsnitt som gäller för filen.
  2. 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.
  3. Starta filnamnet med TemporaryGeneratedFile_
  4. 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 varningsflaggor . 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 alla nya projektmallar elementet <Nullable>enable</Nullable>, och dessa flaggor är inställda på aktiverade.

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 Prop egenskapen null 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.

Se även