Search code examples
.netextension-methods

Is it possible to refactor this extension method?


I have the following extension method:

public static void ThrowIfArgumentIsNull<T>(this T value, string argument) 
    where T : class
{
    if (value == null)
    {
        throw new ArgumentNullException(argument);
    }
}

and this is an example of its usage....

// Note: I've poorly named the argument, on purpose, for this question.
public void Save(Category qwerty)
{
    qwerty.ThrowIfArgumentIsNull("qwerty");
    ....
}

works 100% fine.

But, I don't like how I have to provide the name of the variable, just to help my exception message.

I was wondering if it's possible to refactor the extension method, so it could be called like this...

qwerty.ThrowIfArgumentIsNull();

and it automatically figures out that the name of the variable is 'qwerty' and therefore uses that as the value for the ArgumentNullException.

Possible? I'm assuming reflection could do this?


Solution

  • No, you can't do this. It would be nice, but it's not possible without some sort of AOP getting involved. I'm sure PostSharp can do a nice job, hopefully using attributes, and in Code Contracts it would just be:

    Contract.Requires(qwerty != null);
    

    Ideally I'd like a PostSharp attribute which generates the Code Contracts call - and I'll play around with that at some point - but until then, the extension method you've got is the best approach I've found...

    (If I ever try the PostSharp + Code Contracts approach, I'll certainly blog about it, btw... Mono Cecil might make it reasonably easy too.)

    EDIT: To expand on Laurent's answer, you could potentially have:

    new { qwerty }.CheckNotNull();
    

    And if you had lots of non-nullable parameters, you could have:

    new { qwerty, uiop, asdfg }.CheckNotNull();
    

    This would have to use reflection to work out the properties. There are ways that you could avoid doing the reflection on every access, building a delegate for each property and generally making it whizzy. I may investigate this for a blog post... but it's somewhat icky, and I prefer the idea of being able to just attribute the parameters...

    EDIT: Code implemented, and blog post duly made. Ick, but fun.