I loved this post. I came across it while doing some research on an idea I had to remove a bunch of tedious code that I found myself writing over and over again to validate arguments. I started playing around with your code and made some changes that I thought I would share in case others might find it useful.

namespace ArgVal
{
using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Diagnostics;
using System.Linq;
using System.Linq.Expressions;

public static class ValidateThat
{
public static Argument Argument(Expression<Func> arg)
{
return new Argument(arg);
}
}

public sealed class Argument : IHideObjectMembers
{
[DebuggerNonUserCode]
internal Argument(Expression<Func> arg)
{
switch (arg.Body.NodeType)
{
case ExpressionType.MemberAccess:
this.Name = ((MemberExpression)arg.Body).Member.Name;
break;
case ExpressionType.Parameter:
this.Name = ((ParameterExpression)arg.Body).Name;
break;
default:
throw new ArgumentException(“Expression body must be of type MemberAccess or Parameter.”, “arg”);
}

this.Value = arg.Compile().Invoke();
}

[EditorBrowsable(EditorBrowsableState.Never)]
public TArg Value { get; private set; }

[EditorBrowsable(EditorBrowsableState.Never)]
public string Name { get; private set; }
}

public static class ArgumentValidationExtensions
{
[DebuggerNonUserCode]
public static Argument IsNotNull(this Argument arg)
where T : class
{
if (arg.Value == null)
throw new ArgumentNullException(arg.Name, “Cannot be null.”);

return arg;
}

[DebuggerNonUserCode]
public static Argument IsNotEmpty(this Argument arg)
{
if ((arg.Value != null) && (arg.Value.Length == 0))
throw new ArgumentException(“Cannot be an empty string.”, arg.Name);

return arg;
}

// Additional validation extensions omitted for brevity
}
}

I removed comments and condensed the code for brevity. The IHideObjectMembers interface is also omitted but can be seen here . It along with the EditorBrowsable attributes on the Value and Name properties help to make the fluent API cleaner by removing from intellisense non-validation methods. Hopefully, in my copying and condensing I didn’t screw anything up so that this code could be copied directly and played with.

Note that the EditorBrowsable attribute only works if compiled into an assembly and referenced in some other consuming project. This was killing me yesterday until I found this .

For my purposes, I like how this came out. I like using the Linq expressions for strongly-type references to the arguments therefore removing the need for strings and starting with the static ValidateThat class as opposed to an extension method that sort of “shows up everywhere” once brought into scope with a using declaration.

Thoughts?

Also, I saw that one or two people talked about making this a published API on CodePlex or Google Code. I think it is a cool idea and would start it if anyone is interested. Anyone have a cool name in mind?
NArg anyone? :)

Again, thanks for the great idea. I plan on using it a lot.

But the biggest problem is that it can only be applied to interface and virtual functions, and you have to construct the object using a proxy generator (if the class is a component in an IoC container this is not so big of a problem). Another problem could be performance.

But it’s a nice idea, maybe not the most practical with the current limitations for method interception :)

While it is 100% true that validation is a crosscutting concern, you still have to specify somehow _how_ the arguments should be verified _per usecase_.

You will still have to add some sort of meta data to your methods.

So the benefit is small while you add alot of extra complexity to your app.

If you write “[NotNull]arg” outside of the method , or “arg.NotNull()” inside it doesnt really matter, you are still expressing the same thing.

The AOP version ofcourse come with some benefits, eg you don’t have to specify the arg name and it can be applied to multiple return statements etc.

But all in all, very small benefits for a quite high cost, unless your app already relies on AOP for other tasks.

Also, multiple attributes per argument makes the code somewhat hard to read.

I have only used Castle Dynamic Proxy / Windsor to handle AOP. I find myself using interceptors more and more and should probably move to a framework that offers more out of the box AOP support :)

I’ve got a DbC sample in there that does exactly the same as you :-)

Snip:
public virtual void ReceiveAString(int abc,[NotNull]string def)
…

Snip:
[NotNull] //your version with return: is nicer
public virtual string ReturnAString(int i)
…

Snip:
public object HandleCall(MethodInvocation call)
{
ParameterInfo[] parameters =call.Method.GetParameters();