Considere la aplicación de consola a continuación, que presenta un método con un controlador de captura genérico que capta excepciones del tipo TException.¿Por qué el comportamiento del bloque de manejo catch (TException) difiere bajo el depurador después de instalar Visual Studio 2008?
Cuando esta aplicación de consola se construye con la configuración de la 'depuración' y se ejecuta en el depurador de Visual Studio (es decir, a través de la .vshost.exe *) esto no funciona, tanto en Visual Studio 2005 y Visual Studio 2008.
creo que este problema sólo se produjo después de instalar 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
{
}
En los siguientes casos el código se comporta como se esperaba:
- I f construido con la configuración 'Release', tiene éxito.
- Si se ejecuta directamente a través del * .exe, en lugar de a través de Visual Studio (F5), tiene éxito.
- Si adjunta un depurador poniendo
System.Diagnostics.Debugger.Launch();en la línea 1 deMain(), sigue teniendo éxito.
Cuando la aplicación de consola se inicia desde Visual Studio (2005 o 2008) y, por lo tanto, se ejecuta en ConsoleApplication.vshost.exe, falla.
Aquí está mi salida para el caso fracaso
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
Qué está causando este peculiar fracaso?
Parece que esto ya se planteó en Conectar aquí: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=362422&wa=wsignin1.0 Al parecer ya fijado, pero no está claro qué versión de la CLR, la solución está dentro o cuando se lanzará. –
@Daniel, este fue un problema en el CLR y se solucionará en CLR 4.0 (y, por consiguiente, en la próxima versión de Visual Studio). – JaredPar
Además, el error no existe con la CLR de 64 bits. (https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=386652) –