Published on

C# nullable reference types: Strings aren’t always safe

Authors

EXCEPTION!!!!

Null reference exceptions are the bane of everything that is evil.

We all know them, and they will always hunt us.. They are one of the most common runtime errors in C#, and they always seem to pop up at the worst possible time.. Having a client on the phone in dire need of urgent help, due to the system crashing, just to realize a simple null reference exception is creating havoc.

Since C# 8.0 the compiler will help you prevent them. But that is only if you enable nullable reference types. Enabling things does not magically fix all null reference exceptions. However, it helps us, by highlighting potential dangers lurking around the corner.

We STILL have a hard time understanding when a type should be nullable and when it shouldn't.

The good old days

In older C#, this would compile fine without warnings. But would be a different case when it runs.

string name = null; // Compiles, but runtime crash incoming
Console.WriteLine(name.Length); // Boom 💥

The compiler doesn’t complain, but at runtime you’re left staring at a NullReferenceException.

I know this is not a realistic scenario. You would never intentionally do this. But that's the thing. Can you trust the integrity of the data, and that objects and properties always contains data?

The ? difference

With nullable reference types enabled, you get a contract between your code and the compiler. Very fancy and quite smart. Our IDE's now likes to tell us when we might have an issue.

string? name = null;              // Nullable
string requiredName = "Mathias";  // Non-nullable

Now the compiler warns you if you try to use name without checking it first. This is typically done with a squiggly yellow line under the code that might explode.

if (name != null)
{
    Console.WriteLine(name.Length); // Safe
}

The ? tells the compiler: “this might be null, so warn me if I forget to handle it.”

Best practices

  • Enable it globally in your project file the following way:

    
<Nullable>enable</Nullable>

  • Use ? when null is a valid state for your variable.

  • Use non-nullable references (string, Customer, etc.) when you know they should never be null. This way, you will force yourself to validate and assign values.

  • For the love of god. Don't ignore the warnings. Furthermore, a solution being built that throws 50+ nullable warnings in your face is a good indication that you need to do something about the way you approach nullable types.

Gotcha corner

  • Older libraries without nullability annotations can sneak nulls into your code. Treat those carefully.

  • Sometimes you need the null-forgiving operator (!) to tell the compiler “I know better”:

    string? input = GetInput();
Console.WriteLine(input!.Length);

    But use this sparingly—if you sprinkle ! everywhere, you’re back where you started, and this sort of beats the purpose.

Wrap-up

  • Non-nullable = compiler guarantees you can trust it.
  • Nullable (?) = compiler forces you to think about null.

It is a small C# feature that saves you, and everyone else around you, from major headaches later.

Once you get used to it, you’ll never want to go back. 🚀