Bits of .NET

🔧 The Exclamation Point That Made a Real Bug Go Quiet

Nullable reference types are meant to surface exactly the kind of bug where a value that CAN be null is used as though it can’t be – and the null-forgiving operator (!) exists as an escape hatch for the cases where a developer genuinely knows better than the compiler. The trouble is that it’s just as easy to reach for ! purely to silence a warning that’s actually correct, at which point it stops being a documented assertion and becomes a promise the code doesn’t keep – the exact NullReferenceException the warning was trying to prevent still happens, just later, and with the compiler no longer able to warn about it at all.

🔎 The Problem

public class UserService
{
    public User? FindUser(int id) => _users.FirstOrDefault(u => u.Id == id);
}

public string GetUserDisplayName(int id)
{
    var user = _userService.FindUser(id);

    // The warning here (CS8602, possible null reference) was entirely
    // correct - FindUser genuinely can return null for an unknown id.
    // The ! was added purely to make the warning go away during a
    // cleanup pass, without actually checking whether null is possible
    // in practice at this specific call site.
    return user!.DisplayName;
}

// Months later, a caller passes an id that doesn'"'"'t exist. FindUser
// correctly returns null, exactly as its signature always promised it
// could - and NullReferenceException is thrown at user!.DisplayName,
// in exactly the spot the compiler had already flagged as unsafe.

✅ Fix: Handle the Null Case Instead of Silencing the Warning

• At the actual point a nullable value is used, an explicit null check (an if, a pattern match, or the null-coalescing operator with a sensible fallback or a deliberately thrown, descriptive exception) addresses the warning by actually resolving the possibility it’s pointing at, rather than asserting it away.
• The null-forgiving operator is legitimately appropriate only when a genuine, verifiable guarantee exists that the compiler simply can’t see (a value just checked for null two lines above, in a way the compiler’s flow analysis doesn’t follow) – reaching for it should come with being able to articulate exactly why null is impossible right there, not just to clear a warning during a cleanup pass.
• A project-wide search for ! usage, treated as a periodic code-review item rather than a one-time cleanup, is worth doing specifically because each one represents a claim that null can’t happen – claims that are worth re-verifying occasionally as the surrounding code changes and that guarantee might quietly stop holding.

⚠️ Why This Is a Very Human Way to Introduce the Bug

• Nullable reference type warnings arrive in bulk the first time they’re enabled on an existing codebase, and clearing dozens or hundreds of them under time pressure creates real pressure to reach for the fastest fix available – ! compiles instantly and makes the warning count go down, which looks identical to ‘fixed’ in a warnings-remaining dashboard.
• The bug this creates is strictly worse than having no nullable reference types enabled at all – a codebase that never opted in at least still throws the SAME exception with no false sense of safety, while a codebase full of unjustified ! operators looks fully null-safe at a glance while still containing every one of the original risks.