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. If you have a Pluralsight subscription, you should also check out John Sonmez's Code Contracts course.

Use the coupon code LAUNCHDAY for $10 off!

Learn React

7 Comments

Igor Kulman

Or you can use Fody.NullGuard to weave the boilerplate null checking for you.

Matt

I like this approach but don't like the use of strings. If you use the following code you can avoid them.

public static void IsNull<T>(Expression<Func<T>> expression) where T : class
{
    if (expression.Compile().Invoke() == null)
    {
        throw new ArgumentNullException(GetName(expression));
    }
}

private static string GetName<T>(Expression<Func<T>> expression)
{
    return ((MemberExpression)expression.Body).Member.Name;
}

Now you call the IsNull as:

IsNull(() => someArgument);

No need to input the name of the argument as a string anymore.

Marius Schulz

Igor & Matt: Those are two great approaches as well, thanks!

Matt.R

I use AOP for this, you can decorate the method and ensure that all the params are checked, exceptions are thrown, and you get the safety you want. But your method only contains the code the method needs to do its logic. This improves readability, still fully testable, and reduces repetition.

With obvious caveats/arguments around AOP hiding/segregating certain functionality to another class - which arguably is where it should be anyway.

Alexander Tank

Matt: Take care of compiling expressions, because it can slow down your system heavily!

Instead of compiling the expression you should evaluate it.

See: http://www.minddriven.de/index.php/technology/dot-net/c-sharp/efficient-expression-values

Ehouarn Perret

It might be good also sometimes to have a ThrowIfDefault, especially about value types, cause turning them into Objects can be deadly if you consider the Garbage Collections that can occur later on.

About Compiling Expressions, the general approach or rule is to cache them, (like in ORMs and in many other places to create dynamic setters/ getters, etc.).