Postcondities [MaybeNull] en [NotNull] passen we toe op argumenten, bij het teruggegeven van waarden van methodes of op de waarde van properties. Met [MayBeNull] geven we aan dat een methode null terug kan sturen ook al is de retourwaarde niet null-baar. 

[return: MaybeNull]
public List<Person> FindPersons(Location location)

 Toepassen van [NotNull] op een argument vertelt dat de waarde van dat argument niet null kan zijn nadat de methode is uitgevoerd.  In het onderstaande voorbeeld is de parameter person gegarandeerd niet null als de methode ThrowAlsPersoonNul succesvol was. 

public void ThrowAlsPersoonNul([NotNull] Person? person)
{
    if (person == null)
    {
        throw new ArgumentNullException(nameof(person));
    }
}

Zonder controle geeft de compiler een waarschuwing. Als we deze controle op het resultaat van een zoekopdracht toepassen, verdwijnt de melding. 

var person = personList.Find(p => p.Name == "Al");
ThrowAlsPersoonNul(person);
                               [Hier ontstaat de foutmelding]
var displayName = person.DisplayName;

Conditionele postcondities zijn [NotNullWhen] [MaybeNullWhen] en [NotNullifNotNull]. Het zijn postcondities als eerder genoemde [MaybeNull] en [NotNull]. Het verschil is dat deze condities voorwaardelijk werken. 

NotNullWhen heeft een boolean parameter. In het onderstaand voorbeeld controleert de functie of de string DisplayNaam niet null is: 

public bool IsDisplayNaamIngevuld([NotNullWhen(true)] string? displayNaam)
{
    return (displayNaam != null && displayNaam.Length > 0);
}

Zonder controle bestaat een kans dat de lengte van een null-reference gelezen wordt en ontstaat de foutmelding. Als de code eerst de null-reference controle uitvoert voordat de code de lengte van de string bepaalt verdwijnt de foutmelding.

if (IsDisplayNaamIngevuld(displayName)) 
{
    length = displayName.Length;
}

Na de controle weet de compiler dat displayName onmogelijk nul kan zijn. Zonder onze hulp met de annotatie [NotNullWhen(true)] zou de compiler dat niet kunnen bepalen.

Met de helpende methodes [MemberNotNull] en [MemberNotNullWhen] geef je aan dat je zeker bent dat een property netjes  wordt geïnitialiseerd: 

[MemberNotNull(nameof(DisplayName))]
private void CreateDisplayName()
{
    DisplayName =  $"{FirstName} {Name}";
}

Met de annotaties [DoesNotReturn] en [DoesNotReturnIf] markeer je methoden die nooit een waarde teruggeven, omdat ze alleen een exceptie creëren als iets niet goed gaat. Bijvoorbeeld een methode die controleert of een belangrijke waarde null is en in dat geval een exceptie creëert. Deze annotaties maken de compiler duidelijk dat in de code die volgt de variabele al op null is getest. In dat geval zijn waarschuwingen zijn niet meer nodig. 

[DoesNotReturn]
 private void KritiekeFout()
 {
    throw new InvalidOperationException();
 } 

 public void VerwerkPersoonsGegevens(Person person)
 {
    if (person is null)
    {
        KritiekeFout();
    } 

    // person kan na de vorige methode niet null zijn.
    var naam = person.Name;
    // ...  code 
 }

Als de compiler verkeerde aannames maakt heb je naast de annotaties ook de null-forgiving operator “!” tot je beschikking. Dit geldt ook voor als je de meldingen van de compiler wilt overrulen. Je roept bijvoorbeeld een functie aan waarvan je zeker weet dat de waarde die de functie teruggeeft nooit null kan zijn, terwijl de compiler waarschuwingen blijft geven. Of je leest een property van een object en je bent zeker dat de property onmogelijk null kan zijn. In dat geval los je dat met de “!” operator op. 

In het onderstaand voorbeeld is de variabele persoon niet nullable. We gebruiken het uitroepteken aan het einde van de Find opdracht, omdat we zeker zijn dat de persoon met de naam “Al” in de lijst staat. 

Person person = personList.Find(p => p.Name == "Al")!;

In het volgende statement zijn we zeker dat én de persoon én de naam van de persoon een geldige waarde hebben. We geven dat met de uitroeptekens aan.

var length = person!.Name!.Length;

Null coalsecing operator “?” bestaat al lang. Het vervangt de if-else constructies en maakt de code leesbaarder. Twee nieuwe operatoren, ?? en ??= hebben een vergelijkbare rol. Met ?? operator controleren we of de waarde links van de operator null is. In dat geval geven we die variabele direct een waarde: 

Person person = personList.Find(p => p.Name == "Al") ?? new Person();

Met nul toekenningsoperator initialiseren we een waarde: 

List<Person?>? personList = null;
(personList ??= new List<Person?>()).Add(new Person { Name = "Al" });

Het is ook mogelijk de operatoren achter elkaar te gebruiken: 

var gender = person.Gender?.ToString() ?? nameof(Gender.Unknown);

De operatoren zijn van recht naar links associatief, dus:

a ?? b ?? c   is eigenlijk     a ?? (b ?? c) 

a ??= b ??= c   parset de compiler als a ??= (b ??= c) 

Het aanzetten van de null-bewuste context in bestaande applicaties kan een ware lawine aan waarschuwingen veroorzaken. Er zijn vier mogelijke configuratie opties. De opties zijn als volgt: 

• enable: Alle controles en alle nieuwe taalconstructies zijn ingeschakeld. 
• disable: Alle aspecten van de null-context staan uit, de compiler is volledig compatibel met de eerdere versies van C#.
• warnings: De waarschuwingen zijn aangezet, je code is geanalyseerd, maar de nieuwe taalconstructies in de code zijn niet beschikbaar.
• annotations: je kunt alvast nieuwe taalconstructies gebruiken, maar de null-analyse is uitgeschakeld en de compiler geeft voorlopig geen waarschuwingen.

Deze opties zijn nauwkeurig op drie verschillende niveaus aan te zetten: 

• Voor het hele project 
• Voor een specifiek bestand 
• Voor een specifiek stuk code 

Globaal instellen is eenvoudig door aan het element <Nullable> in het .csproj bestand op een van de  vier mogelijke configuratieopties in te stellen: 

<PropertyGroup>
    <TargetFramework>net6.0</TargetFramework>
    <Nullable>enable</Nullable>
</PropertyGroup>

Instellen op bestandsniveau is mogelijk met de preprocessor directieve #nullable in het bestand. Dat heeft prioriteit op de globale instellingen. 

#nullable enable
#nullable enable warnings
#nullable enable annotations 

#nullable disable
#nullable disable warnings
#nullable disable annotations 

Met de volgende directieven herstellen we het nullable context naar de globale instelling uit het project bestand: 

#nullable restore
#nullable restore warnings
#nullable restore annotations 

Het is mogelijk om de nullable context alleen voor de specifieke stukken code in een bestand ‘aan’ of ‘uit’ te zetten, zo vaak als nodig. Daarvoor gebruik je dezelfde directieven als voor het instellen op bestandsniveau. Indien je de null references zeer serieus neemt, met foutmeldingen in plaats van waarschuwingen, dan kan je voor “Nullable” de instelling “WarningsAsErrors” aanzetten. Waarschuwingen kun je namelijk negeren en foutmeldingen niet. Dit ziet er als volgt uit:

<PropertyGroup>
    <TargetFramework>net6.0</TargetFramework>
    <Nullable>enable</Nullable>
    <WarningsAsErrors>Nullable</WarningsAsErrors>
</PropertyGroup>