Nullable Reference Types

The most common crash in C# programs is a null reference exception. You read a property, the reference holds nothing, and the program stops. The message tells you what happened and nowhere near enough about why.

For most of the language's life, the type system had no opinion on this. A parameter of type string might always hold text, or might hold nothing on Tuesdays. The type said string either way, so the compiler could not help and neither could the reader.

Nullable reference types change what the type says. A string means a value is expected to be there. A string? means it might be absent, on purpose. Once you have written that distinction down, the compiler can follow your code and warn you where the two are mixed up.

#nullable enable

public class Employee
{
    // The type says: an employee always has a full name.
    public string FullName { get; }

    // The question mark says: this one is legitimately absent for some people.
    public string? MiddleName { get; }

    public Employee(string fullName, string? middleName)
    {
        FullName = fullName;
        MiddleName = middleName;
    }
}

public static class Badges
{
    public static int LettersInName(Employee employee)
    {
        int full = employee.FullName.Length;         // no warning: FullName is not nullable
        int middle = employee.MiddleName.Length;     // warning CS8602: possible null dereference
        return full + middle;
    }

    public static int LettersInNameChecked(Employee employee)
    {
        // The compiler follows the check, so inside the if it stops warning.
        if (employee.MiddleName is not null)
        {
            return employee.FullName.Length + employee.MiddleName.Length;
        }

        return employee.FullName.Length;
    }
}

• #nullable enable switches the analysis on for the rest of the file. In practice you set it once for the whole project instead — see the note at the end of this lesson.
• string and string? are the same type at run time. The question mark is an annotation: it records your intent so the compiler can check the code around it.
• CS8602 is the warning that earns its keep. The compiler is not claiming MiddleName is null — it is pointing out that you declared it as possibly null and then read a member from it without checking.
• The second method shows the analysis following control flow. Once an if has ruled null out, the warning disappears inside that branch. You do not annotate the check; the compiler works it out.
• is not null reads better than != null and cannot be affected by a custom equality operator, which makes it the safer habit.

public static class Payroll
{
    // 1. The null-forgiving operator. The ! tells the compiler to stop warning.
    //    It generates no check, so a null still crashes on the next line.
    public static string CodeOrCrash(Employee employee) => employee.TaxCode!;

    // 2. Say what should happen when the value is absent.
    public static string CodeOrDefault(Employee employee) => employee.TaxCode ?? "BR";

    // 3. Fail on purpose, at the point of the problem, with a message that names it.
    public static string CodeOrThrow(Employee employee) =>
        employee.TaxCode ?? throw new InvalidOperationException(
            $"Employee {employee.FullName} has no tax code, so payroll cannot be run.");
}

• The ! is the null-forgiving operator. It means "I know something the analysis does not". Sometimes that is true. Often it means the warning was correct and got silenced.
• ?? is the null-coalescing operator: use the left value unless it is null, in which case use the right. Option 2 makes a decision instead of deferring one.
• Option 3 uses ?? with a throw on the right. The program still fails, but it fails where the missing data was noticed, with a message naming the employee. Compare that with a stack trace two layers away saying only that something was null.
• Of the three, option 1 is the only one that leaves the reader no better informed than before.