Warning: here be dragons. I don’t think this is the right way to check for null arguments, but it was an intriguing idea.
Today on Stack Overflow, I answered a question about checking null arguments. The questioner was already using an extension similar to my own one in MiscUtil, allowing code like this:
{
name.ThrowIfNull("name");
// Normal code here
}
That’s all very well, but it’s annoying to have to repeat the name part. Now in an ideal world, I’d say it would be nice to add an attribute to the parameter and have the check performed automatically (and when PostSharp works with .NET 4.0, I’m going to give that a go, mixing Code Contracts and AOP…) – but for the moment, how far can we go with extension methods?
I stand by my answer from that question – the code above is the simplest way to achieve the goal for the moment… but another answer raised the interesting prospect of combining anonymous types, extension methods, generics, reflection and manually-created expression trees. Now that’s a recipe for hideous code… but it actually works.
The idea is to allow code like this:
{
new { name, input }.CheckNotNull();
// Normal code here
}
That should check name and input, in that order, and throw an appropriate ArgumentNullException – including parameter name – if one of them is null. It uses the fact that projection initializers in anonymous types use the primary expression’s name as the property name in the generated type, and the value of that expression ends up in the instance. Therefore, given an instance of the anonymous type initializer like the above, we have both the name and value despite having only typed it in once.
Now obviously this could be done with normal reflection – but that we be slow as heck. No, we want to effectively find the properties once, and generate strongly typed delegates to perform the property access. That sounds like a job for Delegate.CreateDelegate, but it’s not quite that simple… to create the delegate, we’d need to know (at compile time) what the property type is. We could do that with another generic type, but we can do better than that. All we really need to know about the value is whether or not it’s null. So given a "container" type T, we’d like a bunch of delegates, one for each property, returning whether that property is null for a specified instance – i.e. a Func<T, bool>. And how do we build delegates at execution time with custom logic? We use expression trees…
I’ve now implemented this, along with a brief set of unit tests. The irony is that the tests took longer than the implementation (which isn’t very unusual) – and so did writing it up in this blog post. I’m not saying that it couldn’t be improved (and indeed in .NET 4.0 I could probably make the delegate throw the relevant exception itself) but it works! I haven’t benchmarked it, but I’d expect it to be nearly as fast as manual tests – insignificant in methods that do real work. (The same wouldn’t be true using reflection every time, of course.)
The full project including test cases is now available, but here’s the (almost completely uncommented) "production" code.
using System.Collections.Generic;
using System.Linq;
using System.Reflection;
using System.Linq.Expressions;
public static class Extensions
{
public static void CheckNotNull<T>(this T container) where T : class
{
if (container == null)
{
throw new ArgumentNullException("container");
}
NullChecker<T>.Check(container);
}
private static class NullChecker<T> where T : class
{
private static readonly List<Func<T, bool>> checkers;
private static readonly List<string> names;
static NullChecker()
{
checkers = new List<Func<T, bool>>();
names = new List<string>();
// We can’t rely on the order of the properties, but we
// can rely on the order of the constructor parameters
// in an anonymous type – and that there’ll only be
// one constructor.
foreach (string name in typeof(T).GetConstructors()[0]
.GetParameters()
.Select(p => p.Name))
{
names.Add(name);
PropertyInfo property = typeof(T).GetProperty(name);
// I’ve omitted a lot of error checking, but here’s
// at least one bit…
if (property.PropertyType.IsValueType)
{
throw new ArgumentException
("Property " + property + " is a value type");
}
ParameterExpression param = Expression.Parameter(typeof(T), "container");
Expression propertyAccess = Expression.Property(param, property);
Expression nullValue = Expression.Constant(null, property.PropertyType);
Expression equality = Expression.Equal(propertyAccess, nullValue);
var lambda = Expression.Lambda<Func<T, bool>>(equality, param);
checkers.Add(lambda.Compile());
}
}
internal static void Check(T item)
{
for (int i = 0; i < checkers.Count; i++)
{
if (checkers[i](item))
{
throw new ArgumentNullException(names[i]);
}
}
}
}
}
Oh, and just as a miracle – the expression tree worked first time. I’m no Marc Gravell, but I’m clearly improving :)
Update: Marc Gravell pointed out that the order of the results of Type.GetProperties isn’t guaranteed – something I should have remembered myself. However, the order of the constructor parameters will be the same as in the anonymous type initialization expression, so I’ve updated the code above to reflect that. Marc also showed how it could almost all be put into a single expression tree which returns either null (for no error) or the name of the "failing" parameter. Very clever :)
Jon Skeet's coding blog 
@Steve: The where clause on T checks that *T* is a reference type. The check for IsValueType is on the *property* types.
LikeLike