C# 为什么.NET4.5中的UnobservedTaskException逻辑发生了变化？

正如我们在.net 4.5中看到的，UnobservedTaskException不会使应用程序崩溃

使开发人员更容易基于 NET Framework 4.5更改了默认异常行为 对于未观察到的例外情况。尽管未观察到的例外情况仍在增加 如果出现UnobservedTaskException异常，则进程不会终止 默认情况下。相反，异常由运行时在 无论事件处理程序是否观察到 例外。可以配置此行为。从.NET开始 在Framework 4.5中，您可以使用configuration元素还原到 .NET Framework 4的行为并终止进程：

好吧，假设微软决定改变多线程处理异常的体验，那么为什么它只适用于tpl呢？ 为什么多线程机制的其他部分没有改变？ 例如，以下代码仍然会使应用程序崩溃

static void Main(string[] args)
{
    ThreadPool.QueueUserWorkItem(state => { throw new Exception(); });
    Console.ReadLine();
}

它令人困惑，看起来很奇怪。

---

有人知道这一点吗？

“为什么其他部分……没有改变？”很简单，这会助长坏软件。然而，为什么任务管理制度被简化是一个好问题。但我不明白为什么任务逻辑被改变了。我们可以使用TaskScheduler.UnobservedTaskeException事件来隐藏和记录异常，如果我们想要…

TaskScheduler。UnobservedTaskeException

提供了一种错误的安全感，因为错误的任务只有在完成时才会引发此事件。任务很容易永远无法完成（或者只在处理错误不再有趣时完成），因此甚至不能保证可以实际观察到出现故障的任务。至少不崩溃有保持一致性的好处，因为你可以保证没有未被发现的错误会困扰你-p TPL是一种处理异步计算的机制，但它不直接连接到线程/线程池等。它是它之上的一种抽象，使开发更容易-如果你选择使用更原始的对象，你应该知道你在做什么…@barakcaf，你读过一个问题吗？我不明白你为什么发表评论：）