Ich habe ein Problem mit VS2010, bei dem der Debugger mit einer nicht behandelten Ausnahme stoppt. Die Ausnahme wird jedoch definitiv behandelt. In der Tat, wenn ich Code in den Catch-Block setze, werde ich es treffen, wenn ich F5 drücke. In Debuggen - & gt; Ausnahmen, ich bin definitiv nicht Kontrollkästchen "Thrown" aktiviert, so IMO gibt es absolut keinen Grund für das unbehandelte Ausnahmedialogfeld Pop-Up ...
Ich kann den genauen Code nicht posten, werde aber bald an einer Probe arbeiten. Die Grundidee hinter dem anstößigen Codeabschnitt ist, dass ich einen Thread habe, der mit Hardware spricht, und wenn ich einen Fehler habe, wenn ich mit ihm rede, dann werfe ich einen HardwareException . Der Thread wird mit BeginInvoke gestartet, und die Ausnahme wird im Callback-Handler abgefangen, wenn ich EndInvoke aufruft.
Wenn die Ausnahme im Debugger ausgelöst wird, erhalte ich eine Meldung, die besagt: "HardwareException wird nicht vom Benutzercode verarbeitet." Aber es ist !!!
EDIT - Nun, das macht mich verrückt. Ich habe Beispielcode, der für den Code in meiner Anwendung steht, und sieht so aus:
%Vor%Ich werfe meine HardwareException aus dem Thread und handle dann mit der Ausnahme, wenn EndInvoke aufgerufen wird. Ich denke, Murphy hatte recht, denn wenn ich diesen Beispielcode ausführe, tut er das, was ich erwarte - d. H. Es erscheint keine unbehandelte Ausnahmefehlermeldung in der IDE!
Hier ist die Antwort von Microsoft, Fall 111053102422121. Allen Weng schreibt Folgendes:
Zu Ihrer Information wird CLR die Ausnahme innerhalb des Callbacks erneut ausgeben, wenn Sie EndInvoke () aufrufen. Unten ist eine vereinfachte Version von EndInvoke ():
%Vor%Die Ausnahme wird in der Rückruffunktion oder in der asynchronen Methode behandelt, wenn ein Ausnahmebehandler bereitgestellt wird. So funktioniert es ohne angehängten Debugger.
Wenn Sie es in VS.NET ausführen, scheint der Debugger nur das Vorhandensein des Ausnahmebehandlers in der asynchronen Methode zu überprüfen. Wenn es keinen solchen Handler gibt, würde der Debugger denken, dass die Ausnahme nicht behandelt wird, und eine Fehlermeldung ausgeben, die Sie darüber informiert.
Die Anwendung sollte wie erwartet funktionieren, wenn Sie sie eigenständig ausführen. Wenn die Fehlermeldung beim Debuggen für Sie störend ist, können Sie sie deaktivieren, indem Sie im Dialogfeld "Ausnahme" im Dialogfeld "Ausnahme" die Option "Benutzer nicht behandelt" für "Common Language Runtime Exceptions" (Debug | Exceptions oder STRG + ATL + E) deaktivieren. Oder Sie können try / catch in der asynchronen Methode hinzufügen. Im letzteren Fall wird die Ausnahme auf null gesetzt und in EndInvoke () nicht erneut geworfen.
Ich habe das gleiche Problem, also poste ich diese mögliche Problemumgehung für die Nachwelt:
Fangen Sie in Ihrem Code, der eine Exception in den .NET-Code (HardwareTestThread () im obigen Beispiel) auslöst, die ausgelöste Exception und wickeln Sie sie in einen esoterischen .NET-Exception-Typ ein, für den Sie den "user- nicht behandelte "Option im Dialogfeld Debug & gt; Ausnahmen. In meinem Fall musste ich einer IOException erlauben, durch einige .NET-Codes zurück zu meinem Code zu propagieren. Daher habe ich die IOException abgefangen und in eine AppDomainUnloadedException verpackt, bevor ich sie über den .NET-Code an meinen catch-Block weiterleiten ließ. Ich habe AppDomainUnloadedException gewählt, da user-unhandled standardmäßig deaktiviert ist und sich in der Assembly System.dll befindet. Daher wurde es bereits in mein Projekt importiert, obwohl jede Ausnahme funktionieren sollte, solange Sie die Option "user-unhandled" deaktivieren dafür und es ist Ihnen egal, dass der Debugger in Zukunft nicht auf diese Art von Ausnahme bricht.
Hier ist mein Code, der die IOException umhüllt, die ich propagieren musste:
%Vor%Und hier ist mein Code, wo ich ihn auf der anderen Seite des .NET-Codes abfange, durch den er weitergegeben werden sollte:
%Vor%Tags und Links visual-studio-2010 debugging unhandled-exception