The problem with null checking

The .NET framework is littered with the following code (e.g. from the System.Guid class):

public static Guid ParseExact(String input, String format)
{
    if (input == null)
        throw new ArgumentNullException("input");

    if (format == null)
        throw new ArgumentNullException("format");

    if (format.Length != 1)
    {
        // all acceptable format strings are of length 1
        throw new FormatException(…);
    }
    …
}

A common scenario when creating a publicly accessible method is to validate the parameters being passed into the method and throw an exception when something is amiss.  I used this example as Guid.ParseExact was only added in .NET 4, showing that this is still the ‘Microsoft way’.

But when you do this all over the framework it impacts on performance.  The reality is that in the vast majority of cases this code should be called with a valid string representation of a Guid, at least with a non-null string (with length > 0), yet we have to do the checks every time the method is called.  Even if I can be certain the string represents a real Guid, there is no way for me to skip these checks.  You might say that’s not really a problem, but if I’m writing an ORM (for example) and I’m looking for raw object creation throughput, that overhead starts to become significant.

When ReSharper looked at this problem, they realised that it would be possible to indicate whether null values were expected or not using attributes.  For that reason they added a bunch of attributes that they use to inform their value analysis module, and then they went through the framework and effectively marked it all up.  If you’re using ReSharper (and if not, why not?) you can make use of this code analysis by modifying the above code:

public static Guid ParseExact(
    [NotNull]String input,
    [NotNull]String format)
{
    if (format.Length != 1)
    {
        // all acceptable format strings are of length 1
        throw new FormatException(…);
    }
    …
}

ReSharper will test any code that uses ParseExact and provide a helpful squiggle if it things you are passing in a null when you shouldn’t be.  To be fair the intent here is not to remove the checks themselves, but to make their value analysis not bug you with warnings when they’re unnecessary, but the temptation to remove the checks is powerful.  But this has two big problems.

1. What is the person using your library doesn’t have ReSharper?
2. What if the person using your library ignores the squiggle?

What ReSharper is doing is pretty smart, by analysing the code it can tell if it’s possible a null is sneaking through.  This isn’t done by running the code, but rather by analysing paths through the code.  This can be done at compile time – though it’s not always bomb proof.  When Microsoft Research approached this problem they came up with an even better solution – Code Contracts.

With Code Contracts enabled it is possible to rewrite the above like so :

public static Guid ParseExact(String input, String format)
{
    Contract.Requires(input != null);
    Contract.Requires(format != null);
    Contract.Requires(format.Length != 1);
    ...
}

Which looks eerily like Debug.Assert or Assert.IsTrue statements.  Unlike those two examples though the Contract namespace includes methods that effectively run at compile time to validate constraints.  These methods can also optionally run at runtime, which is useful when a constraint cannot be fully validated at compile time.  Using contracts allows us to move away from those chains of parameter validation code safely.  It even lets us provide information about the outputs of the method using the Contract.Ensures method.  This is a hugely powerful tool in the .NET developer’s arsenal.

But it still suffers from a similar problem to the ReSharper solution – what if the person using your library doesn’t use Code Contracts?  Also, unlike ReSharper, it also modifies the assembly at build time which can be buggy when using other tools, such as PostSharp.   The final nail in the coffin is that ReSharper just doesn’t support Code Contracts in any useful way, and so you’re left implementing both.  It’s for this reason I have repeatedly come back to Code Contracts over the last few years and debated whether to include it in projects.

However, the community does seem to be swinging towards it’s adoption and .NET 4.5 includes the System.Diagnostics.Contract namespace out of the box – but you currently still need to install the Code Contracts extension into VS11 beta if you want to configure it (note if you’re using VS11 that you currently also have to execute ‘devenv /setup’ to complete installation which is a bit of a mess).  If you’re targeting the new framework then there’s no reason to not include Code Contracts as you’re end users won’t have compilation problems – but you may want to encourage them to set up their projects to make use of the contracts you define.  Maybe the Visual Studio team will include the extension when VS11 goes RTM, but that’s not clear.

Until they do, sometimes my code will include examples whilst other times you’ll see the ReSharper attributes.  if you struggle compiling the code you can read the following article, or install the Nuget.  If you want to go old school just create fake attributes that match the signatures used.  If all else fails, you can safely delete the attributes.