views:

180

answers:

2

Consider the console application below, featuring a method with a generic catch handler that catches exceptions of type TException.

When this console application is built with the 'Debug' configuration and executed under the Visual Studio debugger (i.e. through the *.vshost.exe) this fails, in both Visual Studio 2005 and Visual Studio 2008.

I believe this problem only came about after I installed Visual Stuido 2008.

using System;

class Program
{
    static void Main()
    {
        Console.WriteLine(Environment.Version);
        CatchAnException<TestException>();

        Console.ReadKey();
    }

    private static void CatchAnException<TException>()
        where TException : Exception
    {
        Console.WriteLine("Trying to catch a <{0}>...", typeof(TException).Name);
        try
        {
            throw new TestException();
        }
        catch (TException ex)
        {
            Console.WriteLine("*** PASS! ***");
        }
        catch (Exception ex)
        {
            Console.WriteLine("Caught <{0}> in 'catch (Exception ex)' handler.", ex.GetType().Name);
            Console.WriteLine("*** FAIL! ***");
        }
        Console.WriteLine();
    }
}

internal class TestException : Exception
{
}

Under the following circumstances the code behaves as expected:

  • If built with 'Release' configuration, it succeeds.
  • If executed via the *.exe directly, rather than through Visual Studio (F5), it succeeds.
  • If attaching a debugger by putting System.Diagnostics.Debugger.Launch(); on line 1 of Main() it still succeeds.

When the console application is launched from within Visual Studio (2005 or 2008), and therefore executed under ConsoleApplication.vshost.exe, it fails.

Here is my output for the failure case

2.0.50727.3068
Trying to catch a <TestException>...
*** FAIL! ***

Caught <TestException> in 'catch (Exception ex)' handler.
  Expected: <TestException>
    Actual: <TestException>
  Result of typeof(TException) == ex.GetType() is True

What is causing this peculiar failure?

+8  A: 

That's weird indeed. I verified the problem also exists with VB.Net so it's not a C# specific issue. It will need to be confirmed by the core debugger team but it does look like a bug.

Please file a bug on Connect and post the bug number as a comment to my OP so that I can make sure it gets routed to the correct team.

JaredPar
Daniel Fortunov
@Daniel, this was an issue in the CLR and will be fixed in CLR 4.0 (and correspondingly the next version of Visual Studio).
JaredPar
Additionally, the bug does not exist using the 64 bits CLR. (https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=386652)
Jerome Laban
Hmmm, that seems like a long wait for a bugfix to a regression. Is my only option for now to re-write code to avoid using exception type parameters in this way?
Daniel Fortunov
@Daniel, unfortunately yes that appears to be the case. Caveat, I don't work on the CLR so my knowledge of their bug fix process is less than perfect. But I do not believe this fix will be released before the next version of the CLR.
JaredPar
@JaredPar: this post saved my sanity. I was just flat out not believing it. I was about to ask this same question, but it showed up when I entered my title. Thanks again!
John Saunders
+1  A: 

This is a known issue that is caused by a bug in the CLR. It has been fixed in CLR 4.0 (as yet unreleased).

Thanks to JaredPar for the assistance with this. See comments on his answer for more detail and link to the original bug report on Microsoft Connect.

Daniel Fortunov