2

MSDN によると、AppDomain.Unload により、アンロード中の AppDomain 内のすべてのスレッドがスレッド アボート例外をスローします。

ドメイン内のスレッドは、スレッドで ThreadAbortException をスローする Abort メソッドを使用して終了されます。スレッドはすぐに終了する必要がありますが、finally 句で予測できない時間実行し続ける可能性があります。-- MSDNより

したがって、私の理解では、この AppDomain で実行されると予想される場所にコードを記述するたびに、スレッドの中止がいつでも任意のスレッドで発生する可能性があることを期待する必要があります。これは本当ですか？すべてのコードは、ThreadAbortException がいつでもスローされる可能性があると想定する必要がありますか?

実際には、これは実質的に catch(Exception ex)を排除します。これは、ThreadAbortException をキャッチして処理しようとするためです。通常、実際にはログに記録すべきではないエラーをログに記録します (AppDomain のアンロードは実際には例外ではないため)。

不必要な例外処理/エラー ログを回避するために必要なその他の考慮事項はありますか?

4

2 に答える 2

5

いつでも TAE が発生する可能性について、あなたはほとんど正しい期待を持っています。唯一のポイントは、あなたのコードはおそらくすでにこのように書かれているはずだということです.そのうち、AppDomain シャットダウンのシナリオに固有のものではありません。

最後に、キャッチ ブロックで TAE をキャッチし、補正コードを実行できることを知っておく必要があります。それらの唯一の特別な点は、catch ブロックの後にすぐに再スローされることです。そのため、それらを「飲み込む」ことはできません。を使用してそれらを抑制することができますThread.ResetAbort()が、この場合、それはおそらく望ましい効果ではありません。

私たちは皆、次のようなコードを書きました:

public void Foo() {
    try {
        Do.Some.Stuff();
    } catch (Exception ex) {
       Console.Out.WriteLine("Oh noes!");
    }
}

はい、catch ブロックは、TAE や OOM を含むすべてをキャッチします1 。

ここで心に留めておくべきことは、上記のすべての例外について、世界は基本的に終わりに近づいているということです。気にする必要があるのは、処理しているトランザクション上重要なデータが失われたり、悪い状態のままになったりしないようにすることだけです。そのため、通常、トランザクション上安全な I/O のようなものは、Microsoft と Oracle の賢明な人々に任せています。データベースを書く人。たとえば、コードがフラット ファイル I/O を実行していて、ファイルが悪い状態にならないようにする必要がある場合は、非常に全体的な方法で障害モードについて考える必要があります。このファイルを書き途中で電源が落ちる？」

1唯一の例外は、StackOverflow 例外は一般にキャッチできないことです。これは .NET 2.0 での変更です。

于 2012-02-23T15:36:22.800 に答える
1

処理できないThreadAbortExceptionため、例外をキャッチする必要はありません。より技術的に

キャッチできる特別な例外ですが、キャッチブロックの最後で自動的に再度発生します

ここから。

于 2012-02-23T15:35:22.213 に答える