InfiniTec - Henning Krauses Blog

Don't adjust your mind - it's reality that is malfunctioning

From ArgumentException to CodeContracts using Resharper

Resharper (awesome tool btw) makes it really easy to add sanity checks to your code. Just hit Alt+Enter on a method parameter and select “Check parameter for null”:

image

 

This inserts this code:

public static void Test(Frob frob)
{
    if (frob == null) throw new ArgumentNullException("frob");
}

This is great, but once you have started working with Code Contracts (see here for a small tutorial on how to setup Code Contracts) you might want to migrate all those null checks to preconditions. Resharper offers a very powerful feature to to just that: Structural search and replace. It even goes so far that it will highlight parts of code and offers a quick-fix to change conventional argument checking into preconditions. All we need to do is to create a pattern which recognizes an old argument-null check and a replacement pattern:

  1. From the main menu, select ReSharper –> Tools–> Pattern catalog
  2. Click Add pattern
  3. In the search pattern edit box, add this line:
    if ($parameter$ == null) throw new ArgumentNullException($expression$);
  4. In the Replace pattern edit box, add this line:
    Contract.Requires($parameter$ != null);
  5. Click Add Placeholder and select Identifier. Name the placeholder parameter.
  6. Click Add Placeholder again and select Expression. Name the placeholder expression and select System.String as the expression type.
  7. Ensure that the Format after replace and Shorten references options are both checked.
  8. Click Save to persist the new pattern.

Resharper will immediately recognize traditional argument checking code and offer a replacement:

image

After the quickfix has been applied, the method looks like this:

public static void Test(Frob frob)
{
    Contract.Requires(frob != null);
}

If you have enabled runtime checking (as per my last post about this topic), a ContractException will be thrown then the precondition is not met. Obviously, this differs from the previous behavior, which caused this method to throw an ArgumentNullException. But as Eric Lippert states, ArgumentNullExceptions are boneheaded exceptions, and as such should never be cought – they simply shouldn’t happen in production code:

Boneheaded exceptions are your own darn fault, you could have prevented them and therefore they are bugs in your code. You should not catch them; doing so is hiding a bug in your code. Rather, you should write your code so that the exception cannot possibly happen in the first place, and therefore does not need to be caught. That argument is null, that typecast is bad, that index is out of range, you're trying to divide by zero – these are all problems that you could have prevented very easily in the first place, so prevent the mess in the first place rather than trying to clean it up.

(quoted from http://blogs.msdn.com/b/ericlippert/archive/2008/09/10/vexing-exceptions.aspx)


Posted by Henning Krause on Monday, December 13, 2010 11:04 PM, last modified on Monday, December 13, 2010 11:04 PM
Permalink | Post RSSRSS comment feed

 +Pingbacks and trackbacks (1)