Ich habe eine kritische Logik in einem finally-Block (mit einem leeren try-Block), weil ich garantieren möchte, dass der Code ausgeführt wird, selbst wenn der Thread abgebrochen wird. Allerdings möchte ich auch die ThreadAbortException erkennen. Ich habe festgestellt, dass das Wrapping meines kritischen try / finally-Blocks in einem try / catch die ThreadAbortException nicht erfasst. Gibt es eine Möglichkeit, es zu erkennen?
%Vor%Das ist ein seltsames Problem.
Der Code, den Sie gepostet haben sollte funktionieren. Es scheint, als gäbe es eine Art von Optimierung, die sich dazu entscheidet, den Catch-Handler nicht aufzurufen.
Also wollte ich die Ausnahme mit diesem erkennen:
%Vor%(Mein tatsächlicher Code hat gerade in diesem kritischen Codeabschnitt geschlafen, so dass ich sicher sein konnte, dass er danach abbrechen würde.)
Es hat gedruckt:
Thread abgebrochen? Falsch
Hmmm, seltsam, in der Tat!
Also dachte ich darüber nach, dort ein bisschen mehr Arbeit zu machen, um irgendwelche "intelligenten" Optimierungen auszutricksen:
%Vor% Wo AmIEvil gerade ist:
Schließlich hat es gedruckt:
Thread abgebrochen? Wahr
Und da hast du es. Verwenden Sie dies in Ihrem Code:
%Vor% Wo NoOp gerade ist:
Sie können tatsächlich Code in der catch-Anweisung für eine ThreadAbortException ausführen. Das Problem besteht darin, dass die Ausnahme erneut ausgelöst wird, sobald die Ausführung den catch-Block verlässt.
Wenn Sie das Fortsetzen der Ausnahme stoppen möchten, können Sie Thread.ResetAbort () aufrufen. Dies erfordert jedoch volles Vertrauen, und wenn Sie nicht ein bestimmtes Szenario haben, ist es fast sicher das Falsche zu tun.
Lesen Sie eingeschränkte Ausführungsregionen .
Insbesondere wird die Methode RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup sein nützlich hier.
Ich denke nicht, dass es möglich ist.
Warum müssen Sie die ThreadAbortException zuerst behandeln? Der Aufruf von thread.Abort () ist normalerweise ein Zeichen für schlechtes Design. Haben Sie eine Flag-Variable, die, wenn sie auf true gesetzt ist, einfach zurückgibt; von der Thread-Funktion, nach entsprechender Bereinigung natürlich.
Auf diese Weise müssen Sie sich nicht um die Ausnahme kümmern.
Ich stimme arul zu. Der Aufruf von Thread.Abort () ist ein Zeichen für schlechtes Design.
Ich zitiere Peter Ritchie aus MSDN: Thread. Abbrechen (Hervorhebung ist mein):
Es gibt viele Gründe, Thread.Abort und ThreadAbortException nicht zu verwenden
Auf bestimmten Plattformen (wie x64 und IA64) kann der Abbruch vor Monitor.Enter und einem try-Block (sogar mit lock / SyncLock) erfolgen, so dass der Monitor verwaist bleibt. Die ThreadAbortException kann in 3rd-Party-Code auftreten, der nicht zum Behandeln von Threadabbruch geschrieben wurde. Der Thread kann während der Verarbeitung eines finally-Blocks in .NET 1.x abgebrochen werden Verwendet Ausnahmen für die normale Kontrollflusslogik. Eine asynchrone Ausnahme kann die Änderung des Shard-Status oder der Ressourcen unterbrechen und sie beschädigt lassen.
Tags und Links .net multithreading