私は.NETの基準を把握しようとしています.NETの例外が抑制されたり、飲み込まれたり、気づかれずに渡されたりして、そのようなインシデントを検出/疑い/防止/警告する.
.NET Framework 4.5 に関する MSDN のオンライン記事「Timer Class」には、次のように記載されています。
.NET Framework バージョン 2.0 以前では、Timer コンポーネントは、Elapsed イベントのイベント ハンドラーによってスローされたすべての例外をキャッチして抑制します。この動作は、.NET Framework の将来のリリースで変更される可能性があります。
うーん、.NET 4.5 は .NET 2.0 に関連してすでに将来のリリースですか?
これは修辞的な質問ですが、ドキュメントで言及されている特定のケースについてはあまり気にしません。
私が気にして理解したい
のは、.NET例外が抑制されている基準、原則、および根拠は何ですか?
更新（Eugen Rieckの回答に応じて：
質問は次のとおりです。どのスレッドがタイマーティックでスローされた例外の対象となる必要がありますか?
MSDNの記事「例外処理（タスク並列ライブラリ）」を引用：
例外を伝達するタスクを待機しない場合、またはその Exception プロパティにアクセスしない場合、タスクがガベージ コレクションされるときに、.NET 例外ポリシーに従って例外がエスカレートされます。
（どこにも見つからなかった面白い「.NET例外ポリシー」...）
さて、私が理解しているように、STAであり、メインの親スレッドが1つあるWPFアプリに興味があります。
私の願いは、例外が処理されなかった場合にクラッシュすることです。
Update2 (Matt Smith のコメントに応えて):
はい、知っています。引用<ThrowUnobservedTaskExceptions>要素:
Task に関連付けられている例外が監視されていない場合、Wait 操作はなく、親がアタッチされておらず、TaskException プロパティが読み取られていない場合、タスク例外は監視されていないと見なされます。
.NET Framework 4 では、既定では、監視されない例外を持つタスクがガベージ コレクションされると、ファイナライザーは例外をスローし、プロセスを終了します。プロセスの終了は、ガベージ コレクションとファイナライズのタイミングによって決まります。
開発者がタスクに基づいて非同期コードを簡単に記述できるようにするために、.NET Framework 4.5 では監視されない例外に対するこの既定の動作が変更されています。監視されていない例外によって UnobservedTaskException イベントが発生しますが、既定では、プロセスは終了しません。代わりに、イベント ハンドラーが例外を監視するかどうかに関係なく、イベントが発生した後、例外は無視されます。
.NET Framework 4.5 では、アプリケーション構成ファイルの要素を使用して、例外をスローする .NET Framework 4 の動作を有効にすることができます。
質問の膨らみを避け、 Stephen Toubの「.NET 4.5でのタスク例外処理」による説明への参照を取得するために、さらに先に進むのをスキップしました
結局のところ、質問は（本当にこの質問から始めたいと思っていた）私のために確認することです：
- MSDN の「Exception Handling (Task Parallel Library)」に記載されている共通の「.NET 例外ポリシー」はありますか?
- .NET のバージョンに依存していますか、それとも独立していますか?
- それはどこで策定されていますか？