Rozważ poniższą aplikację konsoli, zawierającą metodę z ogólną obsługą catch, która przechwytuje wyjątki typu TException
.Dlaczego zachowanie blokowania catch (TEXception) różni się w debugerze po zainstalowaniu Visual Studio 2008?
Kiedy aplikacja ta konsola jest zbudowany z konfiguracją „debug” i wykonywane pod debugera Visual Studio (czyli poprzez * .vshost.exe) to się nie powiedzie, zarówno w Visual Studio 2005 i Visual Studio 2008.
wierzę, że ten problem tylko doszło po zainstalowaniu programu 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
{
}
w następujących okolicznościach kod zachowuje się zgodnie z oczekiwaniami:
- I f zbudowane z konfiguracją "Release", to się uda.
- Wykonanie bezpośrednio z * .exe, a nie poprzez Visual Studio (F5), powiedzie się.
- Jeśli dołączenie debuggera poprzez wstawienie
System.Diagnostics.Debugger.Launch();
na linii 1 zMain()
, to nadal się powiedzie.
Po uruchomieniu aplikacji konsolowej z poziomu programu Visual Studio (2005 lub 2008), a tym samym uruchomiona w ramach ConsoleApplication.vshost.exe, nie powiedzie się.
Oto moje wyjście na wypadek awarii
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
Co jest przyczyną tego osobliwego niepowodzenie?
Wygląda jak zostało to już podniesione w Połącz tutaj: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=362422&wa=wsignin1.0 Widocznie już ustalone, ale nie wiadomo, co wersja z CLR, w którym znajduje się poprawka lub kiedy zostanie zwolniona. –
@Daniel, był to problem w CLR i zostanie naprawiony w CLR 4.0 (i odpowiednio kolejnej wersji Visual Studio). – JaredPar
Dodatkowo błąd nie istnieje przy użyciu 64-bitowego CLR. (https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=386652) –