Yo, Yo, Check Null

It is a very common practice to check for null in parameters:

public void DoSomething(Foo foo)
{
    if (foo is null)
    {
        throw new ArgumentNullException(nameof(foo));
    }
}

In this blog, I want to talk about parameter null validation: why, when, and how.

Why

It's suggested in many coding style rules, it's followed in many open source projects, but why? What would happen if we don't check whether the parameter is null? What's the benefit of it?

Let's take a look at the following example:

public void PrintCar(Car car)
{
    if (car is null)
    {
        throw new ArgumentNullException(nameof(foo));
    }
    Console.WriteLine(car.Name);
}

In this case, if we don't check whether the parameter is null, it will raise NullReferenceException; if we check, it will raise ArgumentNullException. It looks like the NullReferenceException is gone, but actually we get a new ArgumentNullException. The caller still has to handle it. The number of exceptions doesn't change at all.

Referring to Voldemort as 'You-Know-Who' cannot kill him.

If a method catches an exception and doesn't has the ability to handle it, is it needed to check the null parameters?

Different people have different opinions.

In the blog , the author made a point that it doesn't make sense if you catch the exception and ignore it.

In my opinion, parameters null validation is necessary and useful in most cases.

The first reason is that, NullReferenceException is different from ArgumentNullException. The name of exceptions can help us find the responsible party. If you call the method and you get a ArgumentNullException, you may figure out there is something wrong with the parameters. Just like 40x and 50x status code in HTTP. Bad Request is totally different from Server Error.

The second reason is that, most methods are not stateless. In these stateful methods, an exception in the middle of the method will mess the states up and we cannot roll back easily.

Take a look at this example:

public void CarCounter(Car car)
{
    // #1
    this.CarCount += 1;
    // #2
    this.CarNames.Add(car.Name);
}

When car is null, it will raise an exception in line #2. However, there is a state update in line #1. This may modify the count incorrectly. We need a mechanism like transaction in DB to roll back the executed part of the method. It may be very complicated. And for some cases like notification, the actions are irrevocable.

As a conclusion, in most cases parameter null validation is necessary and useful. It can avoid the execution which shouldn't happen, and it can specify the responsibility of the unexpected exception.

When

As we talked above, it's meaningful to check the null parameters. But should we check all method parameters in our projects?

It depends.

For public method, we don't know what parameters the caller will pass, we should check null parameters before the business logic.

For private methods, we needn't check because we are supposed to know how and where this method is called. In this situation, the null variables should be checked outside of the method before calling it.

It's a good choice to enable the CA1062 Warning. With this warning, we needn't care about when to validate the parameters. Just think about which access modifier should be used, public or private.

How

The following question is, how to check null parameters. The code for validation is verbose and useless. Validating null parameters everywhere will make the code less human-readable.

In the blog , the author went through many ways to validate the parameters. The C# Proposal #2145 about bang operator is very interesting and I am really looking forward to it.

Given Code Contract is deprecated, wrapping the validation into a Helper is a better choice:

internal static class ThrowIf
{
    public static class Argument
    {
        public static void IsNull<T>(T argument, string name)
        {
            if (argument is null)
            {
                throw new ArgumentNullException(name);
            }
        }
    }
}
public void DoSomething(Foo foo)
{
    ThrowIf.Argument.IsNull(foo, nameof(foo));
}

Please let me know if you have another solution. Thanks.

---

References:

• Avoid Check for Null Statement in Java
• Why I Never Null-Check Parameters
• Implementing an Exception Helper Class for Parameter Null Checking
• Code Contracts | MS Docs
• Code Contracts | MS Reserch
• Elegant method parameter validation with Code Contracts support
• Do you throw an argumentexception or argumentnullexception from private methods?
• Should I throw on null parameters in private/internal methods?
• C# 9 Null

---

Update:
Thanks to Sam for suggesting replace == null with is null because the == operator can be overloaded.

Update2:
Thanks to sunilmusinada for suggesting replace hardcode param type with nameof.

Update3:
Thanks to Zohar for pointing out the mistake I made that I put the parameter's type name in exception instead of the parameter's name

Comments

[Sam Ferree]

I like the readability of that API

Minor suggestion, use “argument is null” instead of “argument == null”

The == operator can be overloaded and we can’t guarantee the overload null checks it’s arguments.

[Haiyang Wang]

Thanks Sam! I just updated the sample code with 'is null'. You are totally right.

[Zohar Peled]

Just one note: You want the actual name of the parameter to show in the exception, not the type name, so you need to change the signature to IsNull<T>(T argument, string argumentName) and call it like this:
ThrowIf.Argument.IsNull(foo, nameof(foo)).
Also, you're adding one more method call to the stacktrace, but that's really not a big deal, though.

See fiddle.

[Haiyang Wang]

Yes you are right. I noticed it days ago and wanted to fix this today before anyone discovering the mistake. Then your comment comes LOL

We can fix this by ThrowIf.Argument.IsNull(foo, nameof(foo)), but foo, nameof(foo) is really redundant. I want to get the caller params name in callee directly and I found this: Proposal: Caller Parameter Name #1557. We can get the caller member name, line number, and the file path, but we cannot get the caller's params name.

For now, ThrowIf.Argument.IsNull(foo, nameof(foo)) may be the only way to display the name of params

Thanks for calling out! I just updated the blog according to your suggestion.

[Dimitri Merejkowsky]

Impressive quality for a first blog post! Congrats and welcome.

[amul047]

Check this out, just came out infoq.com/news/2020/06/CSharp-9-Null/

[Haiyang Wang]

Great! I am really looking forward to the new features in C# 9

[sunilmusinada]

I like it. Couldn’t it be better if we use nameof instead of passing the argument.

[Haiyang Wang]

Thanks, I just removed the hardcode params name and use nameof instead. It will be perfect if we can get the caller's params name in callee method. According to Proposal: Caller Parameter Name #1557 it's not possible for now.