Marius Schulz
Marius Schulz
Front End Engineer

Implementing an Exception Helper Class for Parameter Null Checking

I'm a fan of letting my C# code fail hard and fail early. Now, that doesn't mean that I'll implement null checks everywhere, especially not within private methods. If I'm working on a library, though, I like to explicitly check the parameters of its public interface.

By doing that, the caller of a method gets immediate feedback when the provided arguments are invalid. The code is likely to fail anyway when there are unexpected null values. I therefore prefer a helpful guarding ArgumentNullException over a NullReferenceException which occurs deep down within the library internals.

#Traditional Argument Null Checking

Most of the time, checking method parameters for null values is tedious and not a lot of fun, either. We oftentimes find ourselves writing repetitive validation code like this:

public void DoSomething(Foo foo)
{
    if (foo == null)
    {
        throw new ArgumentNullException("foo");
    }

    // ...
}

This boilerplate code gets even worse when you have to check multiple parameters. In that case, the if statements bloat the method and make it look drawn out:

public void DoSomething(Foo foo, Bar bar)
{
    if (foo == null)
    {
        throw new ArgumentNullException("foo");
    }

    if (bar == null)
    {
        throw new ArgumentNullException("bar");
    }

    // ...
}

The parameter null checking in the above example already fills the first 10 lines of the method if you count blank lines. Sure, you could leave out the braces, but even then, you'd need 6 lines. Leaving out the blank lines just looks weird and istn't an option, either.

As part of my ExtraLINQ project, I've introduced a little helper class which encapsulates this kind of parameter validation and exposes a couple of nicely readable methods.

#Encapsulating Argument Null Checking

The structure of checking method arguments is always the same: You check whether the parameter equals null and raise an ArgumentNullException if it does. Why not extract that logic into a dedicated exception helper class?

Here's my implementation of a ThrowIf class:

internal static class ThrowIf
{
    public static class Argument
    {
        public static void IsNull(object argument, string argumentName)
        {
            if (argument == null)
            {
                throw new ArgumentNullException(argumentName);
            }
        }
    }
}

We can now rewrite the introductory example and shorten the parameter checking, which now only takes up 3 lines including the trailing empty line:

public void DoSomething(Foo foo, Bar bar)
{
    ThrowIf.Argument.IsNull(foo, "foo");
    ThrowIf.Argument.IsNull(bar, "bar");

    // ...
}

I like the fact that all parameter guards are now expressed concisely and, if you will, within a single "code section". Plus, the method calls almost read like plain English.

#Writing Additional Validation Methods

One could easily think of additional validation methods performing various checks on parameters of different types. Here are some method ideas that come to my mind:

  • ThrowIf.Collection.IsEmpty
  • ThrowIf.Value.IsZero
  • ThrowIf.Value.IsGreaterThan
  • ThrowIf.Value.IsNegative
  • ThrowIf.ArrayIndex.IsOutOfBounds

Because of the hierarchical structure of the ThrowIf class, the nested classes like Argument and Collection can easily be extended, yet still remain organized and neatly grouped in IntelliSense's code completion window.

#Differences between ThrowIf and Code Contracts

Note that ThrowIf is a plain old C# class that's compiled with the rest of your project. This is different from Code Contracts, which modify the generated IL code to insert their validation logic. To learn more about Code Contracts, head over to the Microsoft Research site.