If you’re here, I bet you already have found the exception message: “Object reference not set to an instance of an object.”
In this series of posts, let’s see some techniques to completely eliminate the NullReferenceException from our code. Let’s start by understanding when NullReferenceException is thrown and a strategy to fix it.
NullReferenceException is thrown when we access a property or method of an uninitialized variable of a reference type. The easier way to solve this exception is to check for null before accessing the members of an object. But C# has introduced new operators and features to avoid this exception.
Let’s write an example that throws NullReferenceException,
varmovie=FindMovie();Console.Write(movie.Name);// ^^^^^// System.NullReferenceException: 'Object reference not set to an instance of an object.'//// movie was null.Console.ReadKey();staticMovieFindMovie(){// Imagine this is a database call that might// or might not return a moviereturnnull;// ^^^^}recordMovie(stringName,intReleaseYear,floatRating);
Notice we returned null from FindMovie(). That caused the NullReferenceException. But, it could be a method that accessed a database and didn’t find anything or an API controller method that didn’t receive a required input parameter.
In our last example, we got a NullReferenceException when we returned null from a method. But, we could also find this exception when we try to loop through a null list or array, for example.
Speaking of returning null, one way to prevent the NullReferenceException is to never pass null between objects. Instead of returning null, let’s use empty lists and strings, or the Null Object pattern. And let’s use intention-revealing defaults for that.
To fix the NullReferenceException, we might be tempted to write a try/catch block around the code that throws it. But, let’s not catch the NullReferenceException.
Let me say that again: don’t throw or catch NullReferenceException.
By any means, please, let’s not write something like this,
try{AMethodThatMightThrowNullReferenceException();}catch(NullReferenceException){// ...// Beep, beep, boop// Doing something with the exception here}
A NullReferenceException is a symptom of an unhandled and unexpected scenario in our code, and catching it won’t handle that. A NullReferenceException is a developer’s mistake.
2. Check for null
The solution for the NullReferenceException is to check for nulls and defense against them.
Let’s fix our previous example by adding a null check. Like this,
varmovie=FindMovie();if(movie!=null)// ^^^^^{// We're safe here...//// No more System.NullReferenceException// at least due to a movie being null Console.Write(movie.Name);}Console.ReadKey();staticMovieFindMovie(){// Imagine this is a database call that might// or might not return a moviereturnnull;// ^^^^}recordMovie(stringName,intReleaseYear,floatRating);
Notice we checked if the movie variable wasn’t null. As simple as that.
Alternatives to check for null
The lack of options isn’t an excuse to not check for null. Since some recent C# versions, and thanks to pattern matching, we have a couple of new ways to check for null. We can use any of these:
if (movie != null) { //... },
if (movie is not null) { //... },
if (movie is { }) { //... }, and,
if (movie is object) { //... }
Some of those don’t look like C# anymore. I still prefer the old if (movie != null) .... Which one do you prefer?
3. Defense against null
If the solution to NullReferenceException were to simply check for null, that wouldn’t be the Billion-Dollar mistake. And I wouldn’t be writing this series.
But the thing is knowing when a reference might be null or not and, therefore, when we should check for it. That’s when we should protect ourselves against null.
To protect against null, inside our methods, let’s check our input parameters and throw a more detailed exception. C# has an exception for missing parameters: ArgumentNullException.
The ArgumentNullException stack trace contains the name of the parameter that was null. That will help us to better troubleshoot our code. Often, the NullReferenceException stack trace doesn’t include what was null in the first place. Happy debugging time!
Let’s check our input parameters,
publicvoidDoSomething(Moviemovie){if(movie==null){thrownewArgumentNullException(nameof(movie))}// Since C# 10, we can also write:// ArgumentNullException.ThrowIfNull(movie);// Beep, beep, boop// Doing something here...}
Notice that instead of waiting for NullReferenceException, we proactively prevented it by checking for a required parameter and throwing a controlled ArgumentNullException.
Voilà! That’s the NullReferenceException and how to fix it by checking for null. Remember, we shouldn’t catch this exception but prevent and prepare for it.
Join my course C# NullReferenceException Demystified on Udemy and learn the principles, features, and strategies to avoid this exception in just 1 hour and 5 minutes.
Welcome to the first Monday Links of 2023. These are five reads I found interesting last month. This time, I found software methodologies was a recurring theme these days.
Why I’m Glad I Lack Passion to BE a Programmer
After a couple of years of working as a software engineer, I started to embrace simplicity. Software exists to satisfy a business need. Perfect software only exists in books. That’s why I started to see the big goal and only use libraries/tools/concepts when there’s a compelling reason to do so. Not all applications need to use Domain-Driven Design with Event Sourcing.
I liked this one: My ideal for software development is to find the simplest solution to the practical problem. I’m not a passionate programmer anymore either.
I can relate to this story. It happens to a friend of a friend of mine. One day his CEO came saying he just closed a really big deal but he didn’t know what they were going to do. Arrrggg!
Apart from a relatable story, this post contains 11 rules about estimations. Like all estimations are simply guesses and by the time developers have enough information to give more accurate estimations, close to the end of a project, it’s already too late.
This article contains some basic principles to design good UI. I don’t like those “are you sure you want to do something?” messages. It’s not a good idea based on this article.
Why Do Many Developers Consider Scrum to Be an Evil Scam?
Like any widespread idea, it gets perverted over time. I’ve been in teams where SCRUM is only adopted to micromanage developers using daily meetings. And the next thing you know is that daily meetings become a narrative of how busy developers are to avoid getting fired.
Why don’t software development methodologies work?
This is an old article I found on Hacker News front page. It showed, years ago, what everybody is complaining about these days. You only need to visit Hacker News or r/programming once every month.
I’ve been in small projects with no methodologies to larger projects with SCRUM as religion. I’ve been there.
I like this paragraph from the article: “My own experience, validated by Cockburn’s thesis and Frederick Brooks in No Silver Bullet, is that software development projects succeed when the key people on the team share a common vision, what Brooks calls ‘conceptual integrity.’“
Apart from the main article, it has really good comments. This is one that resonates with me about the one methodology:
“A single technical lead with full authority to make decisions, with a next tier assistant, associated technical staff, and a non-technical support person. the achievement of the team is then determined by the leadership of the team. the size of the team and project complexity is then limited by the leader and her ability to understand the problem and assign tasks.”
For me, the most successful project are the ones with a small team who knows each other, and everyone knows the main goal and what to do.
In 2022, I wrote two major series of posts: one about SQL Server performance tuning and another one about LINQ.
Once one of my clients asked me to “tune” some stored procedures and that inspired me to take a close look at the performance tuning world. Last year, I took Brent Ozar Mastering courses and decided to share some of the things I learned.
On another hand, I updated my Quick Guide to LINQ to use new C# features and wrote a bunch of new posts about LINQ. In fact, I released one text-based course about LINQ on Educative: Getting Started with LINQ. That’s my favorite C# feature, ever.
I kept writing my Monday Links posts. And, I decided to have my own Advent of Code. I prefer to call it: Advent of Posts. I wrote 22 posts in December. One post per day until Christmas eve. I missed a couple of days. But I consider it a “mission accomplished.”
These are the 5 posts I wrote in 2022 you read the most. In case you missed any of them, here they are:
TIL: How to optimize Group by queries in SQL Server. This post has one of the lessons I learned after following Brent Ozar’s Mastering courses. Well, this one is about using CTEs to speed up queries with GROUP BY.
SQL Server Index recommendations: Just listen to them. Again, these are some of the lessons I learned in Brent Ozar’s Mastering Index Tuning course. I shared why we shouldn’t blindly create indexes recommendations from query plans. They’re only clues. We can do better than that. I have to confess I added every single index recommendation I got before learning these lessons.
Voilà! These were your 5 favorite posts. Hope you enjoy them as much as I did writing them. Probably, you found shorter versions of these posts on my dev.to account. Or the version of some random guy copy-pasted into his own website pretending I was an author on his programming site. Things you find out when you google your own user handle. Arrggg!
Recently, I’ve been reviewing pull requests as one of my main activities. This time, let’s refactor two tests I found on one code review session. The two tests check if an email doesn’t have duplicated addresses before sending it. But, they have a common mistake: testing private methods directly. Let’s refactor these tests to use the public facade of methods.
Always write unit tests using the public methods of a class or a group of classes. Don’t make private methods public and static to test them directly. Test the observable behavior of classes instead.
Here are the test to refactor
These tests belong to an email component in a Property Management Solution. This component stores all emails before sending them.
These are two tests to check we don’t try to send an email to the same addresses. Let’s pay attention to the class name and method under test.
I slightly changed some names. But those are the real tests I had to refactor.
What’s wrong with those tests? Did you notice it? Also, can you point out where the duplicates are in the second test?
To have more context, here’s the SendEmailCommandHandler class that contains the CreateRecipients() method,
usingMediatR;usingMicrosoft.Extensions.Logging;usingMyCoolProject.Commands;usingMyCoolProject.Shared;namespaceMyCoolProject;publicclassSendEmailCommandHandler:IRequestHandler<SendEmailCommand,TrackingId>{privatereadonlyIEmailRepository_emailRepository;privatereadonlyILogger<SendEmailCommandHandler>_logger;publicCreateDispatchCommandHandler(IEmailRepositoryemailRepository,ILogger<CreateDispatchCommandHandler>logger){_emailRepository=emailRepository;_logger=logger;}publicasyncTask<TrackingId>Handle(SendEmailCommandcommand,CancellationTokencancellationToken){// Imagine some validations and initializations here...varrecipients=CreateRecipients(command.Tos,command.Ccs);// ^^^^^varemail=Email.Create(command.Subject,command.Body,recipients);await_emailRepository.CreateAsync(email);returnemail.TrackingId;}publicstaticIEnumerable<Recipient>CreateRecipients(IEnumerable<string>tos,IEnumerable<string>ccs)// ^^^^^=>tos.Select(Recipient.To).UnionBy(ccs.Select(Recipient.Cc),recipient=>recipient.EmailAddress);}}publicrecordRecipient(EmailAddressEmailAddress,RecipientTypeRecipientType){publicstaticRecipientTo(stringemailAddress)=>newRecipient(emailAddress,RecipientType.To);publicstaticRecipientCc(stringemailAddress)=>newRecipient(emailAddress,RecipientType.Cc);}publicenumRecipientType{To,Cc}
The SendEmailCommandHandler processes all requests to send an email. It grabs the input parameters, creates an Email class, and stores it using a repository. It uses the free MediatR library to roll commands and command handlers.
Also, it parses the raw email addresses into a list of Recipient with the CreateRecipients() method. That’s the method under test in our two tests. Here the Recipient and EmailAddress work like Value Objects.
Now can you notice what’s wrong with our tests?
What’s wrong?
Our two unit tests test a private method directly. That’s not the appropriate way of writing unit tests. We shouldn’t test internal state and private methods. We should test them through the public facade of our logic under test.
In fact, someone made the CreateRecipients() method public to test it,
For our case, we should write our tests using the SendEmailCommand class and the Handle() method.
Don’t expose private methods
Let’s make the CreateRecipients() private again. And let’s write our tests using the SendEmailCommand and SendEmailCommandHandler classes.
This is the test to validate that we remove duplicates,
[Fact]publicasyncTaskHandle_DuplicatedEmailInTosAndCc_CallsRepositoryWithoutDuplicates(){varduplicated="duplicated@email.com";// ^^^^^vartos=newList<string>{duplicated,"tomail@mail.com"};varccs=newList<string>{duplicated,"ccmail@mail.com"};varfakeRepository=newMock<IDispatchRepository>();varhandler=newCreateDispatchCommandHandler(fakeRepository.Object,Mock.Of<ILogger<SendEmailCommandHandler>>());// Let's write a factory method that receives these two email listsvarcommand=BuildCommand(tos:tos,ccs:ccs);// ^^^^^awaithandler.Handle(command,CancellationToken.None);// Let's write some assert/verifications in terms of the Email objectfakeRepository.Verify(t=>t.CreateAsync(It.Is<Email>(/* Assert something here using Recipients */),It.IsAny<CancellationToken>());// Or, even better let's write a custom Verify()//// fakeRepository.WasCalledWithoutDuplicates();}privatestaticSendEmailCommandBuildCommand(IEnumerable<string>tos,IEnumerable<string>ccs)=>newSendEmailCommand("Any Subject","Any Body",tos,ccs);
Notice we wrote a BuildCommand() method to create a SendEmailCommand only with the email addresses. That’s what we care about in this test. This way we reduce the noise in our tests. And, to make our test values obvious, we declared a duplicated variable and used it in both destination email addresses.
To write the Assert part of this test, we can use the Verify() method from the fake repository to check that we have the duplicated email only once. Or we can use the Moq Callback() method to capture the Email being saved and write some assertions. Even better, we can create a custom assertion for that. Maybe, we can write a WasCalledWithoutDuplicates() method.
That’s one of the two original tests. The other one is left as an exercise to the reader.
Voilà! That was today’s refactoring session. To take home, we shouldn’t test private methods and always write tests using the public methods of the code under test. We can remember this principle with the mnemonic: “Don’t let others touch our private parts.” That’s how I remember it.
Today I reviewed a pull request and had a conversation about when to use Value Objects instead of primitive values. This is the code that started the conversation and my rationale to promote a primitive value to a Value Object.
Prefer Value Objects to encapsulate validations or custom methods on a primitive value. Otherwise, if a primitive value doesn’t have a meaningful “business” sense and is only passed around, consider using the primitive value with a good name for simplicity.
In case you’re not familiar with Domain-Driven Design and its artifacts. A Value Object represents a concept that doesn’t have an “identifier” in a business domain. Value objects are immutable and compared by value.
Value Objects represent elements of “broader” concepts. For example, in a Reservation Management System, we can use a Value Object to represent the payment method of a Reservation.
TimeStamp vs DateTime
This is the piece of code that triggered my comment during the code review.
We wanted to record when an email is sent, opened, and clicked. We relied on a third-party Email Provider to notify our system about these email events. The DeliveryNotification has an email address, status, and timestamp.
I’d dare to say that using a TimeStamp instead of a simple DateTime in the DeliveryNotification class was an overkill. I guess when “when we have a hammer, everything looks like a finger.”
This is my rationale to choose between value objects and primitive values:
If we need to enforce a domain rule or perform a business operation on a primitive value, let’s use a Value Object.
If we only pass a primitive value around and it represents a concept in the language domain, let’s wrap it around a record to give it a meaningful name.
Otherwise, let’s stick to the plain primitive values.
In our TimeStamp class, apart from Create(), we didn’t have any other methods. We might validate if the inner date is in this century. But that won’t be a problem. I don’t think that code will live that long.
And, there are cleaner ways of writing tests that use DateTime than using a static SystemClock. Maybe, it would be a better idea if we can overwrite the SystemClock internal date.
I’d take a simpler route and use a plain DateTime value. I don’t think there’s a business case for TimeStamp here.
publicclassDeliveryNotification:ValueObject{publicRecipientRecipient{get;init;}publicDeliveryStatusStatus{get;init;}publicDateTimeTimeStamp{get;init;}// ^^^^^^protectedoverrideIEnumerable<object?>GetEqualityComponents(){yieldreturnRecipient;yieldreturnStatus;yieldreturnTimeStamp;}}// Or alternative, to use the same domain language//// public record TimeStamp(DateTime Value);publicenumDeliveryStatus{Created,Sent,Opened,Failed}
If in the “email sending” domain, business analysts or stakeholders use “timestamp,” for the sake of a ubiquitous language, we can add a simple record TimeStamp to wrap the date. Like record TimeStamp(DateTime value).
Voilà! That’s a practical option to decide when to use Value Objects and primitive values. For me, the key is asking if there’s a meaningful domain concept behind the primitive value. Otherwise we would end up with too many value objects or obsessed with primitive values.
