Null used to be everyone's problem at runtime. Now the compiler argues with you about it at compile time — which is a much cheaper place to have the argument.

In 2009, Sir Tony Hoare — the computer scientist who invented the null reference back in 1965 — publicly apologized for it. He called it his "billion-dollar mistake." Not because null itself is useless, but because every mainstream language made it too easy to forget that a reference might be null, and too easy to write code that blows up the moment it isn't.

If you've written any C#, you already know the feeling: everything compiles, everything looks fine, and then at 2 AM in production you get a NullReferenceException because some Customer.Address.City chain hit a null link nobody thought to check. The compiler never warned you. It had no idea Address could be null — as far as it was concerned, every reference type could always be null, so there was nothing special to flag.

In this lesson, you'll learn what Nullable Reference Types (NRT) are, why C# added them, how #nullable enable changes the rules of the game, and how the compiler now catches a huge class of null-reference bugs before your code ever runs.

What Is It?

The Simple Explanation

Nullable Reference Types is a C# feature that lets you tell the compiler, right in your type declarations, whether a reference is allowed to be null or not. A plain string now means "this will always have a value." A string? means "this might be null — you'd better check before you use it."

The compiler then watches how you use each variable and warns you the moment you might be about to dereference something that could be null — before you ever run the program.

The Technical Definition

Nullable Reference Types (NRT) is a C# 8 compiler feature that adds static (compile-time) null-state analysis and annotations to reference types. Inside a nullable-enabled context (turned on with #nullable enable or the project-wide <Nullable>enable</Nullable> setting), every reference type is treated as non-nullable by default. You opt a specific type into nullability by suffixing it with ?, exactly like you already do for value types (int?).

Crucially, this is annotation and flow analysis, not enforcement. The compiler tracks the "null state" of every variable through your code — assigned, possibly-null, definitely-not-null — and issues warnings (not errors, by default) when your code doesn't match what it declared. Nothing about it changes what runs; it changes what the compiler is willing to let slide silently.

Why Does It Exist?

The Problem

Before C# 8, every reference type variable — string, Customer, List<T>, anything that wasn't a struct — could always be null, and the compiler had no opinion about it. This created two related pains:

• No signal in the type itself. A method signature like string GetCity(Customer customer) tells you nothing about whether customer can be null, or whether the returned city might be null. You had to read the implementation — or the documentation, if you were lucky — to find out.
• No safety net. Dereferencing a null reference (customer.Address.City where Address is null) compiled fine and only failed when that exact code path actually ran with a null value — often in production, on a path your tests never exercised.

Developers responded by either defensively null-checking everything (bloating code with checks that are almost always unnecessary) or defensively checking nothing (and hoping). Neither is great. NullReferenceException was — and in code without NRT enabled, still is — one of the most common runtime errors in .NET applications.

The Need

What developers actually needed was a way to encode "can this be null?" directly into the type system — the same way C# already lets you say int (never null) versus int? (nullable) for value types — so the compiler could catch the mistake at the earliest, cheapest possible moment: while you're typing the code, not while a customer is using it.

The Solution

C# 8 introduced Nullable Reference Types. Once you opt in (and every new .NET project template opts in by default since .NET 6), the compiler:

• Treats string as non-nullable — assigning null to it produces a warning.
• Treats string? as nullable — and requires you to check for null (or otherwise prove it isn't null) before dereferencing it.
• Performs flow analysis — if you write if (customer.Address != null), the compiler remembers that inside that block, customer.Address is "known not-null," and stops warning about it there.
• Surfaces every risky dereference as a build warning — visible in your IDE, and optionally promotable to a build-breaking error via <WarningsAsErrors>.

Big Picture

Here's the shift in where a null problem gets caught:

How It Works

// In the .csproj (project-wide, default in .NET 6+ templates):
<Nullable>enable</Nullable>

// Or per-file, at the top of a .cs file:
#nullable enable

public class Customer
{
    public string Name { get; set; }      // never null — required
    public string? MiddleName { get; set; } // optional — may be null
}

void Print(Customer c)
{
    Console.WriteLine(c.MiddleName.Length); //  warning: MiddleName may be null

    if (c.MiddleName != null)
    {
        Console.WriteLine(c.MiddleName.Length); //  no warning — narrowed to non-null here
    }
}

Simple Example

Before — nullable context disabled (the pre-C#-8 world)

public class Order
{
    public string CustomerEmail { get; set; }
}

void SendReceipt(Order order)
{
    // Compiles perfectly fine. No warning.
    // If CustomerEmail was never set, this throws NullReferenceException at runtime.
    Console.WriteLine(order.CustomerEmail.ToUpper());
}

After — nullable context enabled

#nullable enable

public class Order
{
    public required string CustomerEmail { get; set; } // must be provided — never null
}

void SendReceipt(Order order)
{
    // No warning here — CustomerEmail is guaranteed non-null by its type.
    Console.WriteLine(order.CustomerEmail.ToUpper());
}

Meaning: In the "after" version, the compiler itself guarantees CustomerEmail is never null by the time you reach SendReceipt — because anywhere it could have been left null (a missing constructor argument, a missing initializer) would have produced a warning first. You've moved the bug from "discovered by a user" to "flagged by your editor while you type."

Real-World Example

Imagine an API layer that receives a CustomerDto from an HTTP request body and needs to send a welcome email. Without NRT, a missing Email field in the incoming JSON is only discovered when the email service tries to use it:

#nullable enable

public class CustomerDto
{
    public required string Name { get; set; }
    public required string Email { get; set; }   // must always have a value
    public string? PhoneNumber { get; set; }      // genuinely optional
}

public class CustomerController
{
    private readonly IEmailService _emailService;

    public CustomerController(IEmailService emailService)
    {
        _emailService = emailService;
    }

    public void Register(CustomerDto dto)
    {
        // No null-check needed for dto.Email — the type system already guarantees it.
        _emailService.SendWelcomeEmail(dto.Email, dto.Name);

        // PhoneNumber IS nullable, so the compiler forces us to think about the null case:
        if (dto.PhoneNumber is not null)
        {
            _emailService.SendSmsConfirmation(dto.PhoneNumber, dto.Name);
        }
    }
}

If the JSON deserializer produces a CustomerDto with a missing Email, that's now a deserialization or validation problem to catch at the boundary — the rest of the codebase gets to trust the type. PhoneNumber, on the other hand, is honestly optional, so its ? forces every caller to handle the "no phone number" case explicitly instead of hoping nobody forgets.

Analogy

Under the Hood

Common Confusion

1. "Nullable reference types" vs "nullable value types" — same ?, different mechanism

int? is genuinely a different type at runtime: it's shorthand for Nullable<int>, a struct that wraps an int plus a boolean flag saying whether it has a value. That mechanism has existed since C# 2 and is enforced at runtime.

string? is not a different runtime type from string — it's purely a compile-time annotation understood by the compiler's flow analysis. Same symbol, two very different mechanisms depending on whether it follows a value type or a reference type.

2. "My build succeeded, so there are no null bugs" — warnings aren't errors by default

Nullable warnings don't stop the build by default. It's easy to skim past them, especially in a large codebase that already has a backlog of them from before NRT was enabled. Many teams eventually promote specific nullable warnings to build errors (<WarningsAsErrors>CS8600;CS8602;CS8618</WarningsAsErrors>, for example) once the codebase is clean, precisely so they can't silently creep back in.

3. "Enabling NRT makes old code stop working" — it doesn't

Turning on <Nullable>enable</Nullable> in an existing project produces warnings, not compile errors, for every place your code doesn't line up with strict nullability. The program still builds and runs exactly as before. You get to fix things gradually, at your own pace, rather than facing an all-or-nothing migration.

Common Mistakes

Mistake 1 — Silencing every warning with ! instead of fixing the real issue

Suppressing a warning with the null-forgiving operator without actually verifying the value can't be null:

string city = customer.Address.City!; // "trust me, compiler" — but is it actually true?

Instead, actually handle the possibility, or fix the design so the value genuinely can't be null (see the following lesson on null-safe programming for the full toolkit of ?., ??, and pattern checks).

Mistake 2 — Declaring a property non-nullable but never actually initializing it

public class Customer
{
    public string Name { get; set; } //  CS8618: non-nullable property must contain a non-null value when exiting the constructor
}

Provide the value through a constructor, a required modifier, or a default value — don't just ignore the warning, because it means an actual gap exists between what you promised and what you delivered.

Mistake 3 — Assuming NRT is a runtime guarantee

Removing legitimate runtime validation (e.g. at an API boundary, deserializing untrusted JSON) just because the C# type says "non-nullable." Data coming from outside your process — HTTP requests, database rows, third-party libraries compiled without nullable annotations — can still hand you a null even though your C# type claims otherwise.

Keep validating at trust boundaries. NRT protects you from careless mistakes inside your own code; it is not a substitute for input validation.

When Should I Use It?

• Always, in new projects. Every current .NET project template enables it by default — there's essentially no reason to turn it off.
• Gradually, in older codebases. Enable it project-wide, then work through the warnings file by file (or use #nullable disable at the top of files you haven't migrated yet, and remove that line as you clean each one up).
• Especially at public API boundaries — DTOs, service interfaces, library signatures — where clearly documenting "this can be null" or "this can't" saves every consumer a guessing game.

Mental Model

Key Takeaway

Check Your Understanding

You've seen why null reference exceptions were called a billion-dollar mistake, and how NRT gives the compiler the information it needs to catch them early. Let's check your understanding.

You now understand why nullable reference types exist and how the compiler uses them to catch null bugs before they ever ship. Next up: the day-to-day toolkit for writing null-safe code — ?., ??, ??=, and the null-forgiving operator.

dotnetmadeeasy.com — Learn C# and .NET, the right way.