Dela via


Lös nullbarhetsvarningar

Syftet med null-varningar är att minimera risken för att programmet genererar en System.NullReferenceException när den körs. För att uppnå det här målet använder kompilatorn statisk analys och utfärdar varningar när koden har konstruktioner som kan leda till null-referensfel. Du ger kompilatorn information om dess statiska analys genom att tillämpa typanteckningar och attribut. Dessa anteckningar och attribut beskriver nullbarheten för argument, parametrar och medlemmar av dina typer. I den här artikeln lär du dig olika tekniker för att hantera de nullbara varningar som kompilatorn genererar från sin statiska analys. De tekniker som beskrivs här är för allmän C#-kod. Lär dig att arbeta med null-referenstyper och Entity Framework-kärnan i Arbeta med null-referenstyper.

Ogiltiga referenstyper, inklusive operatorerna ? och ! tillåts endast när den nullbara kontexten är inställd på enable eller annotations. Du kan ange den nullbara kontexten med hjälp av Nullablekompilatoralternativet i projektfilen eller med hjälp av #nullable pragma i källkoden.

Den här artikeln beskriver följande kompilatorvarningar:

  • CS8598 - Undertryckningsoperatorn tillåts inte i den här kontexten
  • CS8600 - Konvertera nullliteral eller möjligt null-värde till icke-nullbar typ.
  • CS8601 - Möjlig null-referenstilldelning.
  • CS8602 - Referens för en möjligen null-referens.
  • CS8603 - Möjlig nullreferensretur.
  • CS8604 - Möjligt null-referensargument för parameter.
  • CS8607 - Ett möjligt null-värde kanske inte används för en typ som är markerad med [NotNull] eller [DisallowNull]
  • CS8609 - Nullbarheten hos referenstyper i returtypen överensstämmer inte med den åsidosatta medlemmen.
  • CS8610 - Nullvärdehantering för referenstyper i typparametrarna stämmer inte överens med den överskuggade medlemmen.
  • CS8611 - Nullbarheten för referenstyper i typparametern stämmer inte överens med den partiella metoddeklarationen.
  • CS8613 - Nullabilitet av referenstyper i returtyp stämmer inte överens med implicit implementerad medlem.
  • CS8614 - Nullbarhet för referenstyper i typ av parameter överensstämmer inte med implicit kontrollerad medlem.
  • CS8615 - Referenstyps-nullabilitet i typen stämmer inte överens med implementerad medlem.
  • CS8616 - Nullabilitet för referenstyper i returtyp stämmer inte överens med den implementerade medlemmen.
  • CS8617 - Nullbarhet för referenstyper i parameterens typ överensstämmer inte med den implementerade medlemmen.
  • CS8619 - Nullbarhet för referenstyper inom ett värde överensstämmer inte med måltypen.
  • CS8621 - Nollbarhet för referenstyper i returtyp stämmer inte överens med måldelegat (möjligen på grund av nullbarhetsattribut).
  • CS8622 - Nullability för referenstyper i parameterns typ stämmer inte överens med måldelegaten (möjligen på grund av nullabilitetsattribut).
  • CS8623 - Explicit tillämpning av System.Runtime.CompilerServices.NullableAttribute tillåts inte.
  • CS8628 - Det går inte att använda en nullbar referenstyp när objekt skapas.
  • CS8629 - Nullable-värdetypen kan vara null.
  • CS8632 - Kommentaren för referenstyper som kan ogiltigförklaras bör endast användas i kod i en #nullable anteckningskontext.
  • CS8636 - Ogiltigt alternativ för /nullable; måste vara disable, enable, warnings eller annotations
  • CS8637 - Förväntade enable, disableeller restore
  • CS8639 - Typeof-operatorn kan inte användas på en referenstyp som kan vara null
  • CS8643 - Nullabiliteten för referenstyper i explicit gränssnittsspecifikation stämmer inte överens med gränssnittet som typen implementerar.
  • CS8644-typen - implementerar inte gränssnittsmedlem. Nullbarheten för referenstyper i gränssnittet som implementeras av bastypen matchar inte.
  • CS8667 - Partiella metoddeklarationer har inkonsekvent nullabilitet i begränsningar för typparameter.
  • CS8670 - Objekt- eller samlingsinitierare avrefererar implicit möjligen null-medlem.
  • CS8763 - En markerad [DoesNotReturn] metod bör inte returneras.
  • CS8764 - Nollbarhet för returtyp överensstämmer inte med överskuggade medlem (möjligen på grund av nullattribut).
  • CS8766 - Returtypens nullifierbarhet för referenstyper matchar inte den implicit implementerade medlemmen (möjligen på grund av nullabilitetsattribut).
  • CS8768 - Nullbarhet för referenstyper i returtyp matchar inte implementerat medlem (möjligen på grund av nullabilitetsattribut).
  • CS8769 - Nullbarhet för referenstyper i typ av parameter matchar inte den implementerade medlemmen (möjligen på grund av nullabilitetsattribut).
  • CS8770 - Metoden saknar [DoesNotReturn] annotation för att matcha implementerad eller åsidosatt medlem.
  • CS8819 - Nullability för referenstyper i returtyp matchar inte partiell metoddeklaration.

Anteckning

Den statiska analysen kan inte alltid härleda i vilken ordning, i ett specifikt scenario, metoder används och om metoden slutförs utan att utlösa ett undantag. Dessa kända fallgropar beskrivs väl i avsnittet Kända fallgropar.

Du hanterar nästan alla varningar med någon av fem tekniker:

  • Konfigurera nullable-sammanhanget.
  • Lägga till nödvändiga nullkontroller.
  • Lägga till eller ta bort ? eller ! nullbara annotationer.
  • Lägga till attribut som beskriver null-semantik.
  • Initiering av variabler på ett korrekt sätt.

Om du är nybörjare på att använda null-referenstyper ger översikt över nullbara referenstyper en bakgrund om vad nullbara referenstyper löser och hur de fungerar för att ge varningar om möjliga misstag i koden. Du kan också kontrollera vägledningen om migrering till nullbara referenstyper för att lära dig mer om att aktivera nullbara referenstyper i ett befintligt projekt.

Konfigurera null-kontext

Följande varningar anger att du inte har angett den nullbara kontexten korrekt:

  • CS8632 - Kommentaren för referenstyper som kan ogiltigförklaras bör endast användas i kod i en #nullable anteckningskontext.
  • CS8636 - Ogiltigt alternativ för /nullable; måste vara disable, enable, warnings eller annotations
  • CS8637 - Förväntad enable, disableeller restore
  • CS8668 - Förväntat warnings, annotationseller slutet av direktivet

Om du vill ställa in den nullbara kontexten på rätt sätt har du två alternativ:

  1. Konfiguration på projektnivå: Lägg till elementet i <Nullable> projektfilen:

    <PropertyGroup>
     <Nullable>enable</Nullable>
    </PropertyGroup>
    
  2. Konfiguration på filnivå: Använd #nullable förprocessordirektiv i källkoden:

    #nullable enable
    

Den nullbara kontexten har två oberoende flaggor som styr olika aspekter:

  • Annoteringsflagga: Styr om du kan använda för att deklarera nullbara referenstyper och ? för att undertrycka enskilda varningar.
  • Varningsflagga: Styr om kompilatorn genererar nullabilitetsvarningar

Detaljerad information om nullbara kontexter och migreringsstrategier finns i:

Felaktig anteckningssyntax

Dessa fel och varningar indikerar att användningen av ! eller ? kommentaren är felaktig.

  • CS8598 - Undertryckningsoperatorn tillåts inte i den här kontexten
  • CS8623 - Explicit användning av System.Runtime.CompilerServices.NullableAttribute tillåts inte.
  • CS8628 - Det går inte att använda en nullbar referenstyp när objekt skapas.
  • CS8639 - Typeof-operatorn kan inte användas på en Nullable-referenstyp

Den ? kommentaren i en deklaration anger att variabeln kan vara null. Det anger inte någon annan körtidstyp. Båda följande deklarationer är av samma körtidstyp

string s1 = "a string";
string? s2 = "another string";

? är ett tips till kompilatorn om förväntningarna på null-värden.

Den !-annoteringen på ett uttryck anger att du vet att uttrycket är säkert och bör antas inte vara null.

  • Du måste använda dessa anteckningar, inte System.Runtime.CompilerServices.NullableAttribute i koden.
  • Eftersom ? är en anteckning, inte en typ, kan du inte använda den med typeofeller new uttryck.
  • Den ! operatorn kan inte tillämpas på ett variabeluttryck eller en metodgrupp.
  • !-operatorn kan inte användas till vänster om en medlemsåtkomstoperator, till exempel obj.Field!.Method().

Möjlig avreferering av null-värde

Den här uppsättningen varningar varnar dig om att du avrefererar en variabel vars null-tillstånd kanske är null. Dessa varningar är:

  • CS8602 - Avreferensieringen av en möjligen null referens.
  • CS8670 - Objekt- eller samlingsinitialiseraren avrefererar implicit en möjligen null-medlem.

Följande kod visar ett exempel på var och en av föregående varningar:

class Container
{
    public List<string>? States { get; set; }
}

internal void PossibleDereferenceNullExamples(string? message)
{
    Console.WriteLine(message.Length); // CS8602

    var c = new Container { States = { "Red", "Yellow", "Green" } }; // CS8670
}

I föregående exempel beror varningen på att Container, c, kan ha ett null-värde för egenskapen States. Att tilldela nya tillstånd till en samling som kan vara null orsakar varningen.

Om du vill ta bort dessa varningar måste du lägga till kod för att ändra variabelns null-tillstånd till not-null innan du avrefererar den. Insamlingsinitierarens varning kan vara svårare att upptäcka. Kompilatorn identifierar att samlingen kanske-null när initieraren lägger till element i den.

I många fall kan du åtgärda dessa varningar genom att kontrollera att en variabel inte är null innan du avrefererar den. Tänk på följande exempel som lägger till en null-kontroll innan du avrefererar parametern message:

void WriteMessageLength(string? message)
{
    if (message is not null)
    {
        Console.WriteLine(message.Length);
    }
    
}

I följande exempel initieras bakgrundslagringen för States och accessorn set tas bort. Användare av klassen kan ändra innehållet i samlingen och lagringen för samlingen är aldrig null:

class Container
{
    public List<string> States { get; } = new();
}

Andra tillfällen när du får dessa varningar kan vara felaktiga larm. Du kan ha en privat verktygsmetod som testar för null. Kompilatorn vet inte att metoden ger en null-kontroll. Tänk dig följande exempel som använder en privat verktygsmetod: IsNotNull

public void WriteMessage(string? message)
{
    if (IsNotNull(message))
        Console.WriteLine(message.Length);
}

Kompilatorn varnar för att du kanske avrefererar null när du skriver egenskapen message.Length eftersom dess statiska analys avgör att message kan vara null. Du vet att IsNotNull ger en nullkontroll och när den returnerar truebör nulltillstånd för message vara icke-null. Du måste berätta dessa fakta för kompilatorn. Ett sätt är att använda operatorn null-förlåtande, !. Du kan ändra -instruktionen WriteLine så att den matchar följande kod:

Console.WriteLine(message!.Length);

Operatorn null forgiving gör uttrycket not-null även om det var kanske-null utan operatorn ! tillämpad. I det här exemplet är en bättre lösning att lägga till ett attribut i signaturen IsNotNullför :

private static bool IsNotNull([NotNullWhen(true)] object? obj) => obj != null;

System.Diagnostics.CodeAnalysis.NotNullWhenAttribute Informerar kompilatorn om att argumentet som används för parametern obj inte är null när metoden returnerar true. När metoden returnerar falsehar argumentet samma null-tillstånd som det hade innan metoden anropades.

Tips

Det finns en omfattande uppsättning attribut som du kan använda för att beskriva hur dina metoder och egenskaper påverkar null-tillstånd. Du kan lära dig mer om dem i språkreferensartikeln om nullbar statisk analysattribut.

Om du åtgärdar en varning för att avreferera en variabel som kanske är null involverar det en av tre tekniker:

  • Lägg till en nullkontroll som saknas.
  • Lägg till null-analysattribut på API:er för att påverka kompilatorns statiska analys med null-tillstånd . Dessa attribut informerar kompilatorn när ett returvärde eller argument ska vara kanske null eller inte null efter att metoden anropats.
  • Använd null-förlåtande operatorn ! på uttrycket som tvingar tillståndet till att vara inte-null.

Möjlig null tilldelad till en icke-inullerbar referens

Den här uppsättningen med varningar varnar dig om att du tilldelar en variabel vars typ inte kanulleras till ett uttryck vars null-tillstånd kanske är null. Dessa varningar är:

  • CS8597 - Genererat värde kan vara null.
  • CS8600 - Konvertering av nullliteral eller möjligt null-värde till en icke-nullerbar typ.
  • CS8601 - Möjlig null-referenstilldelning.
  • CS8603 - Möjlig nullreferensretur.
  • CS8604 - Möjligt null-referensargument för parameter.
  • CS8605 - Avboxa ett eventuellt nullvärde.
  • CS8625 - Det går inte att konvertera nullliteral till icke-nullbar referenstyp.
  • CS8629 - Nullable-värdetypen kan vara null.

Kompilatorn genererar dessa varningar när du försöker tilldela ett uttryck som kanske är null till en variabel som inte kan inaktiveras. Till exempel:

string? TryGetMessage(int id) => "";

string msg = TryGetMessage(42);  // Possible null assignment.

De olika varningarna visar information om koden, till exempel tilldelning, avboxningstilldelning, returinstruktioner, argument till metoder och utsända uttryck.

Du kan vidta någon av tre åtgärder för att åtgärda dessa varningar. En är att lägga till anteckningen ? för att göra variabeln till en nullbar referenstyp. Den ändringen kan orsaka andra varningar. Om du ändrar en variabel från en icke-nullbar referens till en nullbar referens ändras standardvärdet null-state från not-null till maybe-null. Kompilatorns statiska analys hittar instanser där du avreferera en variabel som är kanske null-.

De andra åtgärderna instruerar kompilatorn att tilldelningens högra sida inte är null. Uttrycket till höger kan vara null-markerat före tilldelningen, enligt följande exempel:

string notNullMsg = TryGetMessage(42) ?? "Unknown message id: 42";

Föregående exempel visar tilldelning av returvärdet för en metod. Du kommenterar metoden (eller egenskapen) för att ange när en metod returnerar ett värde som inte är null. Anger System.Diagnostics.CodeAnalysis.NotNullIfNotNullAttribute ofta att ett returvärde inte är null när ett indataargument inte är null. Ett annat alternativ är att lägga till null-förlåtande operatorn ! till höger:

string msg = TryGetMessage(42)!;

Att åtgärda en varning för att tilldela ett uttryck som kanske är null till en variabel som inte är null, involverar en av fyra tekniker.

  • Ändra den vänstra sidan av tilldelningen till en nullbar typ. Den här åtgärden kan introducera nya varningar när du avrefererar variabeln.
  • Utför en null-kontroll före tilldelningen.
  • Kommentera API:et som genererar den högra sidan av tilldelningen.
  • Lägg till den null-förlåtande operatorn på höger sida av tilldelningen.

Icke-inullerbar referens har inte initierats

Den här uppsättningen varningar varnar dig om att du tilldelar en variabel vars typ inte kan nulliseras till ett uttryck vars null-tillstånd kanske är null. Dessa varningar är:

  • CS8618 - Icke-nullbar variabel måste innehålla ett värde som inte är null när konstruktorn avslutas. Överväg att deklarera det som nullbart.
  • CS8762-parametern - måste ha ett värde som inte är null när du avslutar.

Se följande klass som ett exempel:

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

Varken FirstName eller LastName är garanterade att vara initialiserade. Om den här koden är ny kan du överväga att ändra det offentliga gränssnittet. Föregående exempel kan uppdateras på följande sätt:

public class Person
{
    public Person(string first, string last)
    {
        FirstName = first;
        LastName = last;
    }

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

Om du behöver skapa ett Person objekt innan du anger namnet kan du initiera egenskaperna med ett standardvärde som inte är null:

public class Person
{
    public string FirstName { get; set; } = string.Empty;
    public string LastName { get; set; } = string.Empty;
}

Ett annat alternativ är att ändra dessa medlemmar till null-referenstyper. Klassen Person kan definieras på följande sätt om null ska tillåtas för namnet:

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

Befintlig kod kräver ibland andra ändringar för att informera kompilatorn om null-semantiken för dessa medlemmar. Den kan ha flera konstruktorer och klassen har en privat hjälpmetod som initierar en eller flera medlemmar. Du kan flytta initieringskoden till en enda konstruktor och se till att alla konstruktorer anropar den med den gemensamma initieringskoden. Eller så kan du använda attributen System.Diagnostics.CodeAnalysis.MemberNotNullAttribute och System.Diagnostics.CodeAnalysis.MemberNotNullWhenAttribute . Dessa attributen informerar kompilatorn om att en medlem är icke-null efter att metoden har returnerats. 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";
    }
}

Slutligen kan du använda null-förlåtande operatorn för att ange att en medlem har initierats i annan kod. Tänk dig till exempel följande klasser som representerar en Entity Framework Core-modell:

public class TodoItem
{
    public long Id { get; set; }
    public string? Name { get; set; }
    public bool IsComplete { get; set; }
}

public class TodoContext : DbContext
{
    public TodoContext(DbContextOptions<TodoContext> options)
        : base(options)
    {
    }

    public DbSet<TodoItem> TodoItems { get; set; } = null!;
}

Egenskapen DbSet initieras till null!. Det talar om för kompilatorn att egenskapen är inställd på ett värde som inte är null . I själva verket utför basen DbContext initieringen av uppsättningen. Kompilatorns statiska analys tar inte upp det. Mer information om hur du arbetar med null-referenstyper och Entity Framework Core finns i artikeln arbeta med nullbara referenstyper i EF Core.

Att åtgärda en varning för att inte initiera en icke-inullerbar medlem omfattar någon av fyra tekniker:

  • Ändra konstruktorerna eller fältinitierarna så att alla icke-inullerbara medlemmar initieras.
  • Ändra en eller flera medlemmar till null-typer.
  • Kommentera eventuella hjälpmetoder för att ange vilka medlemmar som har tilldelats.
  • Lägg till en initialiserare för null! för att indikera att medlemmen initieras i en annan del av koden.

Osammanstämmighet i nullvärdeshantering

Många varningar indikerar nullabilitetsmissmatchningar mellan signaturer för metoder, delegater eller typparametrar.

  • CS8608 - Nullability av referenstyper i typen matchar inte den överridna medlemmen.
  • CS8609 - Nullbarhet för referenstyper i returvärde matchar inte den överskridna metoden.
  • CS8610 - Nullabiliteten för referenstyper i en typparameter matchar inte överskriven medlem.
  • CS8611 - Nullegenskap för referenstyper i typparametern matchar inte partielle metoddeklarationen.
  • CS8612 - Nullabilitet för referenstyper i typen överensstämmer inte med den implicita implementerade medlemmen.
  • CS8613 - Nullabiliteten för referenstyper i returtypen stämmer inte överens med den implicita implementerade medlemmen.
  • CS8614 - Nullability för referenstyper i typ av parameter matchar inte implicit implementerad medlem.
  • CS8615 - Nullability för referenstyper av typen matchar inte implementerad medlem.
  • CS8616 - Nollvärdeskapaciteten för referenstyper i returtypen matchar inte den implementerade medlemmen.
  • CS8617 - Nullability för referenstyper i typ av parameter matchar inte implementerad medlem.
  • CS8619 - Referenstypernas nullabilitet i värdet stämmer inte överens med måltypen.
  • CS8620-argument - kan inte användas för parametern på grund av skillnader i referenstypernas nullbarhet.
  • CS8621 - Nullabilitet för referenstyper i returtypen överensstämmer inte med måldelegaten, möjligen på grund av nullattribut.
  • CS8622 - Nullabiliteten för referenstyper i parametrens typ stämmer inte överens med måldelegaten (möjligen på grund av nullattribut).
  • CS8624-argumentet - kan inte användas som utdata på grund av skillnader i referenstypernas nullbarhet.
  • CS8631 - Typen kan inte användas som typparameter i den generiska typen eller metoden. Nullabilitet för typargumentet matchar inte villkorstypen.
  • CS8633 - Nullbarhet i begränsningarna för typparametern för metoden matchar inte begränsningarna för typparametern i gränssnittets metod. Överväg att använda en explicit gränssnittsimplementering istället.
  • CS8634 - Typen kan inte användas som typparameter i den generiska typen eller metoden. Nullbarhet för typargument matchar inte villkoret "klass".
  • CS8643 - Nullability för referenstyper i explicit gränssnittsspecifikation stämmer inte överens med gränssnittet som implementeras av typen.
  • CS8644-typen - implementerar inte gränssnittsmedlem. Nullbarheten för referenstyper i gränssnittet som implementeras av bastypen matchar inte.
  • CS8645 - Member finns redan med i gränssnittslistan för typen med olika typer av nullbarhet för referenstyper.
  • CS8667 - Partiella metoddeklarationer har inkonsekvent nullabilitet i begränsningar för typparameter.
  • CS8714 - Typen kan inte användas som typparameter i den generiska typen eller metoden. Nullbarhet för typargument matchar inte villkoret "notnull".
  • CS8764 - Nullbarhet av returtyp matchar inte överskriven medlem (möjligen på grund av nullbarhetsattribut).
  • CS8765 - Nullbarhet för parameterns typ stämmer inte överens med återdefinierad medlem (möjligen på grund av nullattribut).
  • CS8766 - Nullabiliteten för referenstyper i returtypen matchar inte den implicit implementerade medlemmen (möjligen på grund av nullabilitetsattribut).
  • CS8767 - Nullbarhet för referenstyper i typ av parameter matchar inte det implicit implementerade medlemmet (eventuellt på grund av nullbarhetsattribut).
  • CS8768 - Nullbarhet för referenstyper i returtyp matchar inte den implementerade medlemmen (möjligen på grund av nullbarhetsattribut).
  • CS8769 - Nullbarhet för referenstyper i parametrarnas typ överensstämmer inte med den implementerade medlemmen (möjligen på grund av nullattribut).
  • CS8819 - Nullabiliteten hos referenstyper i returtypen matchar inte deklarationen av den partiella metoden.

Följande kod visar CS8764:

public class B
{
    public virtual string GetMessage(string id) => string.Empty;
}
public class D : B
{
    public override string? GetMessage(string? id) => default;
}

Föregående exempel visar en virtual metod i en basklass och en override med annan nullabilitet. Basklassen returnerar en icke-nullbar sträng, men den härledda klassen returnerar en nullbar sträng. string Om och string? är omvända tillåts det eftersom den härledda klassen är mer restriktiv. På samma sätt bör parameterdeklarationer matcha. Parametrar i åsidosättningsmetoden kan tillåta null även om basklassen inte gör det.

Andra situationer kan generera dessa varningar. Du har ett matchningsfel i en gränssnittsmetoddeklaration och implementeringen av den metoden. Eller en ombudstyp och uttrycket för ombudet skiljer sig åt. En typparameter och typargumentet skiljer sig åt i nullabilitet.

Om du vill åtgärda dessa varningar uppdaterar du lämplig deklaration.

Koden matchar inte attributdeklarationen

I föregående avsnitt beskrevs hur du kan använda -attribut för nullable statisk analys för att informera kompilatorn om null-semantiken i din kod. Kompilatorn varnar dig om koden inte följer löftena för det attributet:

  • CS8607 - Ett möjligt null-värde kanske inte används för en typ som är markerad med [NotNull] eller [DisallowNull]
  • CS8763 - En markerad [DoesNotReturn] metod bör inte returneras.
  • CS8770-metoden - saknar [DoesNotReturn] anteckning för att matcha implementerad eller åsidosatt medlem.
  • CS8774 - Member måste ha ett värde som inte är null när du avslutar.
  • CS8775 - Member måste ha ett värde som inte är null när du avslutar.
  • CS8776 - Member kan inte användas i det här attributet.
  • CS8777-parametern - måste ha ett värde som inte är null när du avslutar.
  • CS8824-parametern - måste ha ett värde som inte är null när den avslutas eftersom parametern inte är null.
  • CS8825 - Return-värdet måste vara icke-null eftersom parametern inte är null.

Tänk på följande metod:

public bool TryGetMessage(int id, [NotNullWhen(true)] out string? message)
{
    message = null;
    return true;

}

Kompilatorn skapar en varning eftersom parametern message har tilldelats nulloch metoden returnerar true. Attributet NotNullWhen anger att det inte ska ske.

För att åtgärda dessa varningar uppdaterar du koden så att den matchar förväntningarna för de attribut som tillämpas. Du kan ändra attributen eller algoritmen.

Fullständigt växeluttryck

Switch-uttryck måste vara uttömmande, vilket innebär att alla indatavärden måste hanteras. Även för icke-nullbara referenstyper null måste värdet redovisas. Kompilatorn utfärdar varningar när null-värdet inte hanteras:

  • CS8655 - Switch-uttrycket hanterar inte några null-indata (det är inte uttömmande).
  • CS8847 - Switch-uttrycket hanterar inte några null-indata (det är inte uttömmande). Ett mönster med en "when"-sats kan dock matcha det här värdet.

Följande exempelkod visar det här villkoret:

int AsScale(string status) =>
    status switch
    {
        "Red" => 0,
        "Yellow" => 5,
        "Green" => 10,
        { } => -1
    };

Indatauttrycket är en string, inte en string?. Kompilatorn genererar fortfarande den här varningen. Mönstret { } hanterar alla icke-null-värden, men matchar nullinte . För att åtgärda dessa fel kan du antingen lägga till ett explicit null ärende eller ersätta { } med _ mönstret (ignorera). Mönstret för kassering hanterar null utöver andra värden.