Bits of .NET

🔧 The Null Check That Was Secretly a Pattern Match All Along

Switch expressions and is-pattern checks in modern C# handle null gracefully by design – matching null against a type pattern simply fails to match rather than throwing, which is exactly why ‘if (value is Customer c)’ is safe to write even when value is null, and why a switch expression with a null case reads cleanly. The part that catches experienced developers off guard is relying on that same graceful non-throwing behavior as if it were equivalent to an explicit null check everywhere, when a pattern that looks like it covers ‘anything else’ doesn’t always cover null the way a plain default case nor an unconstrained discard pattern might silently suggest it does.

🔎 The Problem

public decimal GetDiscount(Customer? customer) => customer switch
{
    PremiumCustomer p => p.Rate,
    StandardCustomer s => s.Rate,
    _ => 0.05m // looks like it covers "everything else" including null -
               // and it DOES, which is actually the trap: a genuinely
               // unexpected null silently gets the default discount
               // instead of surfacing as the bug it probably is.
};

// Call site, months later:
var discount = GetDiscount(LookupCustomerOrNull(id)); // returns null when the
                                                        // id was deleted - and
                                                        // nobody notices, since
                                                        // 0.05m is a perfectly
                                                        // plausible-looking value.

✅ Fix: Decide Deliberately Whether Null Deserves Its Own Case

• Adding an explicit null pattern as its own switch arm (null => throw new ArgumentNullException(…), placed before the discard) forces a genuinely unexpected null to fail loudly and immediately, rather than quietly falling into whatever the catch-all case happens to return.
• Making the parameter type non-nullable (Customer instead of Customer?) wherever null genuinely should never be a valid input shifts the responsibility to the caller and to nullable-reference-type warnings at compile time, rather than to a runtime switch expression that has to decide what to do about it.
• Reviewing every discard pattern (_) in a switch over a reference type specifically for whether it’s meant to include null is worth doing once per switch, since the discard pattern matching null is easy to intend and easy to forget having intended.

⚠️ Why the Language Behaves This Way on Purpose

• Making pattern matching null-safe by default (rather than throwing a NullReferenceException on every null input) is a deliberate design choice that makes null-conditional logic easier to write correctly in the common case – the cost is that it also makes it easy to handle null exactly the same as any other unmatched value without noticing.
• This is most dangerous specifically in catch-all arms that return a plausible default value rather than an obviously-wrong one (0, empty string, false) – an obviously wrong default gets noticed quickly, while a plausible one can hide a real null for a long time.