本文将记录 dotnet 的一个已知问题,且是设计如此的问题。假定有一个 TaskCompletionSource 对象,此对象的 Task 没有被任何地方引用等待。在 TaskCompletionSource 被调用 SetException 或 TrySetException 方法时,将会记录一个存在异常且未捕获的 Task 对象。此 Task 对象将会在被 GC 回收时,进入 TaskScheduler.UnobservedTaskException 事件里面,尽管没有明确副作用,但是会吓到不明真相的开发者

最简的复现步骤是如下代码

    public App()
    {
        TaskScheduler.UnobservedTaskException += TaskSchedulerOnUnobservedTaskException;

        var taskCompletionSource = new TaskCompletionSource();
        taskCompletionSource.SetException(new Exception());
    }

    private void TaskSchedulerOnUnobservedTaskException(object? sender, UnobservedTaskExceptionEventArgs e)
    {
    }

以上是一个 WPF 应用,选 WPF 应用是可以比较方便等待 GC 的触发

以上代码将创建一个 TaskCompletionSource 对象,且此对象的 Task 没有地方等待,意味着在 SetException 设置的异常,将会设置到一个未等待的 Task 上。按照 dotnet 的设计,如果一个 Task 存在未捕获的异常,将会在 Task 被回收的时候,进入 TaskScheduler.UnobservedTaskException 事件

进入 TaskScheduler.UnobservedTaskException 事件的异常,按照设计,在 .NET Framework 4.5 之后,也就是包含所有的 dotnet core 版本,都不会导致应用崩溃。进入 TaskScheduler.UnobservedTaskException 事件的异常,只是用来告诉开发者,某个地方也许存在一个小坑

规避方法是: 无视;找个好地方等待一下 Task 对象;不要 SetException 方法,而是换成 SetResult 方法


本文会经常更新,请阅读原文: https://blog.lindexi.com/post/dotnet-%E8%AE%B0-TaskCompletionSource-%E7%9A%84-SetException-%E5%8F%AF%E8%83%BD%E5%B0%86%E5%BC%82%E5%B8%B8%E8%AE%B0%E5%BD%95%E5%88%B0-UnobservedTaskException-%E7%9A%84%E9%97%AE%E9%A2%98.html ,以避免陈旧错误知识的误导,同时有更好的阅读体验。

如果你想持续阅读我的最新博客,请点击 RSS 订阅,推荐使用RSS Stalker订阅博客,或者前往 CSDN 关注我的主页

知识共享许可协议 本作品采用 知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议 进行许可。欢迎转载、使用、重新发布,但务必保留文章署名林德熙(包含链接: https://blog.lindexi.com ),不得用于商业目的,基于本文修改后的作品务必以相同的许可发布。如有任何疑问,请 与我联系

无盈利,不卖课,做纯粹的技术博客

以下是广告时间

推荐关注 Edi.Wang 的公众号

欢迎进入 Eleven 老师组建的 .NET 社区

以上广告全是友情推广,无盈利