"Possible null reference argument": Fix CS8604 in C#

You've enabled nullable reference types in your C# project, and now the compiler is warning you: "Possible null reference argument for parameter." That's CS8604, and it's one of the most valuable—and most misunderstood—compiler warnings in modern .NET. The instinct is often to silence it with a ! (null-forgiving operator) and move on. But that warning is the compiler catching a future NullReferenceException for you. Throwing it away with a suppression is like removing a smoke detector because it's annoying.

This guide explains what CS8604 really means, why it fires, and how to fix it properly—without lying to the compiler. If you're debugging null-reference crashes in production, an error tracking system will show you exactly where they originate. But preventing them in the first place is even better.

What CS8604 means: The compiler saw a potential null

When nullable reference types are enabled (via <Nullable>enable</Nullable> in your .csproj or #nullable enable at the file level), every reference type is assumed to be non-nullable by default. A method signature like this:

public void ProcessOrder(Order order)
{
    // Compiler assumes `order` must not be null
}

tells the compiler: "I will never pass null here." If you then pass something that might be null, the compiler warns you. That's CS8604. It's the compiler saying: "Hey, you promised this parameter wouldn't be null, but you're passing something that could be."

The warning fires at the call site, not in the method. You're the one breaking the contract.

The core confusion: Compile-time flow analysis, not runtime enforcement

When you see CS8604, the compiler is warning you based on its static flow analysis of your code. It traces the origin of the value you're passing and says, "That path could lead to null." But the compiler can only see so far. It can't know that a JSON deserializer will always populate a field, or that a reflection call will never return null. It's a tool with limited information.

That's why suppressing CS8604 with ! is dangerous:

public void ProcessOrder(Order order)
{
    // ...
}

Order? orderFromJson = DeserializeOrder(jsonData);
ProcessOrder(orderFromJson!); // Suppressing CS8604 with !

You're telling the compiler: "Trust me, this is never null." But you don't know that for sure. At runtime, if orderFromJson actually is null, you'll get a NullReferenceException inside ProcessOrder, and the ! made it impossible for the compiler to catch it earlier.

Fix 1: Guard and narrow the type

The safest fix is to check before you call:

Order? orderFromJson = DeserializeOrder(jsonData);

if (orderFromJson is null)
    return; // or throw, or handle gracefully

ProcessOrder(orderFromJson); // Safe; compiler knows it's not null now

When you use if (x is null) or if (x != null), the compiler's flow analysis narrows the type inside that block. After the check, orderFromJson is no longer Order?—it's Order. Passing it to a method expecting Order is safe, and there's no warning.

This is the gold standard: you've actually validated the value before using it. If null is unexpected and indicates a bug, use an early return or throw. If null is sometimes okay, handle it explicitly.

Fix 2: Make the parameter signature honest

If a parameter really might be null sometimes, declare it as nullable:

public void ProcessOrder(Order? order)
{
    if (order is null)
    {
        Console.WriteLine("Order is null; skipping.");
        return;
    }
    
    // Process order...
}

Now callers are free to pass null without a warning. The contract is explicit: "This method can handle null." You've moved the responsibility from the caller to yourself. This is the right choice when null is a valid input state.

The key is being honest in your signature. If a parameter should never be null, declare it non-nullable and make callers validate. If it can be null, declare it nullable and handle it inside the method.

Fix 3: Throw at the boundary

Use ArgumentNullException.ThrowIfNull() (available in .NET 6+) at the start of your method. This is a cleaner approach than manual guard clauses and is explored in depth in the guide to ArgumentNullException parameter validation. Modern versions of this call include an attribute that tells the compiler: "If this method returns normally, this parameter is definitely not null."

public void ProcessOrder(Order? order)
{
    ArgumentNullException.ThrowIfNull(order);
    // After this line, compiler knows `order` is not null
    
    order.Id.ToString(); // No warning; compiler trusts ThrowIfNull
}

Call this at the entry point—a public method, a constructor, an event handler—anywhere you cross a boundary. Inside private helpers, trust that callers did the validation upstream.

Fix 4: Pattern matching

You can use pattern matching to check and use a value in one step:

Order? orderFromJson = DeserializeOrder(jsonData);

if (orderFromJson is { } order)
{
    ProcessOrder(order); // No warning
}

The is { } pattern checks for non-null and binds a non-nullable variable. It's concise and clear about intent.

Fix 5: Null-coalescing with a fallback

If you have a default or alternative value, use ??:

Order? orderFromJson = DeserializeOrder(jsonData);
Order orderToProcess = orderFromJson ?? new Order { Id = "default" };

ProcessOrder(orderToProcess); // No warning

This is useful when you can provide a sensible default, but it's not a validation strategy—it's about always having a non-null value to work with.

When attributes make the difference

Some methods—particularly TryParse and custom validation helpers—return a bool to signal success, with an out parameter for the result. The compiler doesn't know that if the method returns true, the out parameter is definitely non-null:

public bool TryGetOrder(int id, out Order? order)
{
    // ...
    if (found)
    {
        order = loadedOrder;
        return true;
    }
    
    order = null;
    return false;
}

// Later:
if (TryGetOrder(123, out var order))
{
    ProcessOrder(order); // CS8604: compiler doesn't trust the out param
}

Add the [NotNullWhen(true)] attribute to tell the compiler the truth:

public bool TryGetOrder(int id, [NotNullWhen(true)] out Order? order)
{
    // ...
}

// Now:
if (TryGetOrder(123, out var order))
{
    ProcessOrder(order); // No warning; compiler understands the pattern
}

Other useful attributes:

• [MemberNotNull] — signals that a method (often an initializer) guarantees a field is non-null after it returns.
• [NotNullIfNotNull("parameterName")] — if one parameter is non-null, another will be too. Useful for transformations like string.IsNullOrEmpty(x) ? null : x.Trim().

These are in System.Diagnostics.CodeAnalysis. The compiler understands them, and so do analyzers.

Real-world sources of "possible null" errors

JSON deserialization

var options = new JsonSerializerOptions();
Order? order = JsonSerializer.Deserialize<Order>(json, options);
// order is Order? even if the JSON should always have certain fields

ProcessOrder(order); // CS8604

Fix: Check before processing, or mark parameters as nullable. This is a common entry point for null values from external APIs and data sources—understanding how to read stack traces from deserialization errors helps you trace back to the source.

LINQ methods like FirstOrDefault()

var order = orders.FirstOrDefault(o => o.Id == id);
// order is Order? (could be null if no match)

ProcessOrder(order); // CS8604

Fix: Check with if (order is not null) or use First() (throws) if you know a match exists.

Dictionary TryGetValue out parameter

if (orderCache.TryGetValue(id, out var order))
{
    ProcessOrder(order); // CS8604 without [NotNullWhen] attribute
}

Fix: The built-in TryGetValue has the attribute, but custom methods need it too.

EF Core navigation properties

var customer = await db.Customers.FindAsync(id);
var orders = customer.Orders; // Orders could be null if not loaded

foreach (var order in orders) // CS8604 or runtime null-ref
{
    ProcessOrder(order);
}

Fix: Use .Include() or .ThenInclude() to load navigation properties explicitly, or check for null. Uninitialized navigation properties are a common source of InvalidOperationException errors—another class of exception worth understanding and preventing in your code.

Libraries without nullable annotations

If you're consuming a library that hasn't been annotated for nullable reference types, you can't trust its nullability guarantees. Use #nullable disable for that region, or add your own validation:

var result = LegacyLibrary.GetResult();
ArgumentNullException.ThrowIfNull(result); // Make it safe

Scoping NRTs and treating warnings as errors

You don't have to enable NRTs for your entire project at once. Use #nullable enable at the file level and incrementally migrate:

#nullable enable

public class ModernCode
{
    public void Process(string input) // input is non-nullable
    {
        // ...
    }
}

For new code, enable it. For legacy code, migrate as you touch it. You can also treat nullable warnings as errors in your csproj for stricter enforcement:

<PropertyGroup>
  <Nullable>enable</Nullable>
  <WarningsNotAsErrors>CS8604</WarningsNotAsErrors>
  <!-- or treat all warnings as errors and exclude specific ones -->
</PropertyGroup>

This forces the team to fix CS8604 warnings instead of suppressing them. It's a team discipline decision, but it pays off in fewer runtime null-reference crashes.

The real benefit: Shifting left

CS8604 is the compiler helping you catch a class of bugs before they reach production. When you see it, resist the urge to add !. Instead, ask: "Is this parameter actually nullable? Should it be? Or should I validate before I call this method?" That question, asked at every CS8604 warning, leads to clearer contracts, better error handling, and fewer surprises in production.

The investment in fixing CS8604 properly—via guards, honest signatures, and validation attributes—pays dividends when your code is running and you need to debug a production error. You'll have fewer NullReferenceException crashes to deal with, because the compiler caught the issue during development. And when null-reference errors do slip through from external sources like JSON or reflection, an error tracking system gives you the full context—stack trace, affected users, breadcrumbs—to fix it fast.