Skip to content

Avoiding the NullReferenceException

Sponsor: Do you build complex software systems? See how NServiceBus makes it easier to design, build, and manage software systems that use message queues to achieve loose coupling. Get started for free.

Learn more about Software Architecture & Design.
Join thousands of developers getting weekly updates to increase your understanding of software architecture and design concepts.

Easily, by a landslide, the most common exception I’ve run into in C# is the NullReferenceException.  Second would be an InvalidOperationException.  But NullReferenceException wins as most occurred exception hands down.  This quick post shows how we can start avoiding the NullReferenceException. I despise null.  I despise null checks.  What if there was a way to get rid of null checks?  Luckily there is. Last year I was at a talk by Reid Evans, Getting Started with Functional Programming in F#.   He touched on it and I’ve been using an implementation in C# ever since.


an option type or maybe type is a polymorphic type that represents encapsulation of an optional value; e.g., it is used as the return type of functions which may or may not return a meaningful value when they are applied.
Optional Library For this example, I’m going to use the Optional package.  There are many similar type libraries available on NuGet, but this one is fairly feature rich and serves the purpose for my example.


So I’m going to walk through a trivial example of a ASP.NET Core application that is going to return some customer data.  The sample code below will throw a NullReferenceException when the incoming customerId is not found in our database.

Null Check

Obvious answer is to wrap the return statement in an if statement to verify the customer returned from the _customerRepository is not null.  If it is, then return a 404.


Our CustomerRepository, could’ve thrown a InvalidOperationException or another type of exception if the customer didn’t exist.  But what if instead it returned an Option<Customer> and never returned null. In the example below, our _customerRepository.GetOptionById(int) now returns an Option<Customer>. This now forces us to specify how to handle if there is a value, and if it is null.


Hopefully this a a simple example of the Option type and how it can be a gateway to removing null and NullReferenceException from your code.  Take a deeper look at the docs for the Optional library as there are many other great examples. Are you using an implementation of Option/Maybe?  Let me know in the comments or on Twitter.

6 thoughts on “Avoiding the NullReferenceException”

  1. I prefer to raise an exception like RecordNotFoundException from GetById. If I call several times GetById, I can wrap all these calls with a try/catch and handle the exception one time.

    And I generally don’t return null from a method. If a method can return null, I prefix it with a Try (TryGetById).

    1. My example was pretty contrived. I wouldn’t return null, but it was just to provide an example. Another scenario would of been if the Customer would of had a property that could of been null. Ultimately, the purpose was to demonstrate that an option type eliminates the null, null checks, exceptions and exception handling.

      1. It’s really wrapping the null check in an abstraction rather than eliminating it. There’s no doubt that abstractions like this can be helpful, but they can also make code harder to read. Your last example, I’d suggest, is harder to read than the one before with the explicit null check.

Leave a Reply

Your email address will not be published. Required fields are marked *