Feature Request: Exclude code from coverage

I second that and also have a variation.

I like to thrown an exception from my switch statement's default label to notify me early of an error in my code.  For example:

enum ItemStatus { Open, Closed };

...

switch(item.Status)

{
     case ItemStatus.Open:

          ... do something for open status

          break;

     case ItemStatus.Closed:

          ... do something fo closed status

          break;

     default:

          throw new Excpetion("Unknown Status:  " + item.Status);

}

If everything works as it's supposed to, the throw in the default case is never executed and in fact, can never execute as long as Open and Closed are the only two values.  My switch is meant to notify me of a bug in my code in the case that I later add another member to ItemStatus but forget to add a corresponding case to my switch statement.  It would be great to be able to do something like this so that the intentionally dead default case doesn't negatively impact my coverage statistics:

// dotCover disable coverage

     default:

          throw new Excpetion("Unknown Status:  " + item.Status);

// dotCover restore coverage

This could also be used in circumstances like this:

switch(...)
{

     case ... :

          SomeClass.AMethodThatAlwaysThrowsException();

          //dotCover disable coverage

          break;

          //dotCover restore coverage

}

Hi David,

Couple of points:

• I think your idea for excluding code blocks using comments is good and would have useful applications;
• You can test the default case in your example, and if time allows it, should consider doing it:

     public class Program
     {
          public static void Main(string[] args)
          {
               // this will compile
               MyMethod(ItemStatus.Open);

               // and this
               MyMethod(ItemStatus.Open);

               // and so will this - note the cast
               MyMethod( (ItemStatus)42 );     // this will throw an exception at runtime, just as you wanted
          }

          private void MyMethod(ItemStatus status)
          {
               switch(status)
                {
                      case ItemStatus.Open:
                           Console.WriteLine("Open");
                           break;
                    case ItemStatus.Closed:

                         Console.WriteLine("Closed");
                         break;

Sure, casting some int to ItemStatus would work, however, my tests are more or less integration tests and the switch block I was examing when this idea popped into my head is about 50 calls up the call stack, making that really difficult to do.  I simpler scenarious, I would not hesitate to do that.

On the same way, I have this example :

        <TestMethod()>
         <ExpectedException(GetType(ArgumentNullException))>
        Public Sub Constructor_WithNothingParameter()
 
            Dim Args() As String = Nothing
            Dim target As CommandLineParser = New Gfk.GfkKynetec.SharedLibraries.Component.CommandLineParser(Args)
        End Sub