.NET 抑制异常的（可能未记录的）案例背后的基本原理是什么？

Question

我正在尝试掌握 .NET 标准，在该标准中，当 .NET 异常被抑制、吞下或通过时被忽视，以便检测/怀疑/预防/警惕此类事件。

.NET Framework 4.5 上的 MSDN 在线文章“计时器类”指出：

在 .NET Framework 2.0 及更早版本中，Timer 组件 捕获并抑制由事件处理程序抛出的所有异常 已过的事件。此行为可能会在未来版本中更改 .NET 框架

嗯，.NET 4.5 是否是与 .NET 2.0 相关的未来版本？
虽然这是一个修辞问题，但我不太关心文档中提到的具体案例。

我关心和想了解的是：
.NET 异常被抑制的标准、原则和基本原理是什么？

更新（回应Eugen Rieck's answer:

所以问题是：哪个线程应该受到异常的影响 在计时器滴答声上抛出？

引用MSDN文章“Exception Handling (Task Parallel Library)”：

如果您不等待传播异常的任务，或者访问 它的 Exception 属性，异常是根据 垃圾回收任务时的 .NET 异常策略。

（我在任何地方都找不到的有趣的“.NET 异常策略”......）

嗯，我对 WPF 应用程序很感兴趣，据我了解，它是 STA 并且有一个主父线程。
我的愿望是，如果未处理任何异常，它会崩溃。

Update2（回应 Matt Smith 的评论）：

是的，我知道。 引用<ThrowUnobservedTaskExceptions> Element：

如果未观察到与任务关联的异常， 没有Wait操作，没有附加父级，并且 未读取 TaskException 属性 认为任务异常 不被观察。

在 .NET Framework 4 中，默认情况下，如果任务具有 未观察到的异常被垃圾收集，终结器抛出一个 异常并终止进程。进程的终止 由垃圾收集和终结的时间决定。

为了让开发者更容易编写基于 任务，.NET Framework 4.5 更改了此默认行为 未观察到的异常。未观察到的异常仍然会导致 要引发 UnobservedTaskException 事件，但默认情况下， 进程不会终止。相反，该异常在之后被忽略 引发事件，无论事件处理程序是否观察到 例外。

在 .NET Framework 4.5 中，您可以使用 应用程序中的元素 配置文件以启用 .NET Framework 4 的抛出行为 一个例外。

我只是跳过进一步讨论以避免问题的膨胀并获得Stephen Toub's "Task Exception Handling in .NET 4.5"的解释参考

问题毕竟是（真的想从这个问题开始）为我确定：

• 有没有在MSDN "Exception Handling (Task Parallel Library)" 中提到的通用“.NET 异常策略”，在一个地方明确制定？
• .NET 版本依赖还是独立？
• 它是在哪里制定的？

Answer 1

以下是该政策的链接（在 .net 2.0 中已更改），此后一直保持不变： http://msdn.microsoft.com/en-us/library/ms228965.aspx

Answer 2

这很可能只是一个实施问题：

• 计时器滴答在线程池线程上运行
• 定时器本身不属于线程
• 创建计时器的线程可能不再运行（或存在）

所以问题是：哪个线程应该受到计时器滴答时抛出的异常的影响？对此没有简单的答案，因此简单地抑制异常（即运行每个刻度并在其周围隐含 try ... catch）是回避这个问题的一种方法。