Referenstyper som kan ogiltigförklaras
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 null
genererar 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 null
avreferera . 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 null
dess 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ärdetnull
i annan kod. - Kompilatorn utfärdar inte varningar när koden tilldelar ett kanske null-uttryck till en variabel som kan vara null.
- Variabeln kan bara derefereras när kompilatorn kan garantera att värdet inte
Alla icke-nullbara referensvariabler har standardvärdet null-state not-null. Alla null-referensvariabler har det inledande null-tillståndet kanske-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 refererarT?
till motsvarande null-referenstyp. Om till exempelT
är enstring
T?
, så är enstring?
. - Om typargumentet för
T
är en värdetyp refererarT?
till samma värdetyp,T
. Till exempel, omT
är enint
,T?
är också enint
. - Om typargumentet för
T
är en nullbar referenstyp refererarT?
till samma null-referenstyp. Om till exempelT
är enstring?
T?
, så är även enstring?
. - Om typargumentet för
T
är en nullbar värdetyp refererarT?
till samma nullbara värdetyp. Om till exempelT
är enint?
T?
, så är även enint?
.
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 somT
inte kan ogiltigförklaras (till exempelstring
). Kompilatorn skapar en varning om du använder en nullbar referenstyp, till exempelstring?
förT
. - Villkoret
class?
innebär attT
det måste vara en referenstyp, antingen icke-nullbar (string
) eller en nullbar referenstyp (till exempelstring?
). När typparametern är en nullbar referenstyp, till exempelstring?
, ett uttryck förT?
referenser som har samma null-referenstyp, till exempelstring?
. - Villkoret
notnull
innebär att det måste vara en referenstyp somT
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 dessutomT
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åndet not-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.
Se även
Feedback
https://aka.ms/ContentUserFeedback.
Kommer snart: Under hela 2024 kommer vi att fasa ut GitHub-problem som feedbackmekanism för innehåll och ersätta det med ett nytt feedbacksystem. Mer information finns i:Skicka och visa feedback för