如果你的程序抛了异常,你是怎么处理的呢?等待程序崩溃退出?还是进行补救?

如果是做 UI 开发,很容易就找到 Dispatcher.UnhandledException 事件,然后在事件中进行补救。如果补救成功,可以设置 e.Handled = true 来阻止异常继续让程序崩溃退出。但是,如果是后台线程抛出了异常呢?并没有 Dispatcher 可以用。所以我们就束手就擒让程序自己退出吗?


WPF 和 Windows Forms 都是微软的框架,为了照顾初学者,微软会默认每一个开发者都不会正确地处理异常。于是在异常发生之后,微软 Windows 会假设开发者并不知道如何应对以便让应用程序正常工作,就擅自将应用程序进程结束掉,以便防止应用程序自己内部产生奇怪的状态和错误,避免对系统环境造成不可逆的严重后果。

能够写出异常处理代码的开发者,微软会默认他们懂了异常处理。

写出了监听 Dispatcher.UnhandledException 事件的开发者,微软会认为他们已经学会了如何在 UI 线程中处理异常。于是允许开发者设置 e.Handled = true 来标记异常已被正确处理,程序可以不用退出了。

还有一个事件 Appdomain.CurrentDomain.UnhandledException,然而这个事件却并不允许开发者标记 e.Handled = true。因为微软认为,应用程序域中所有的线程发生异常都会进入这个事件中,大多数开发者都不明白这些线程这些异常是怎么回事,所以不认为这些开发者具备正确处理这些异常的能力。比如 WPF 的触摸模块发生了异常,开发者知道如何恢复吗?并不知道,还不如结束掉程序然后重启呢!

在这个事件中,有一个属性 IsTerminating 指示是否应用程序正因为这次异常准备退出,不过开发者并不能拿这个属性做些什么。

但还是要照顾更高级的开发者的,于是祭出新的配置——legacyUnhandledExceptionPolicy

app.config 文件的 <runtime> 节点中添加如下代码:

<legacyUnhandledExceptionPolicy enabled="1"/>  

加上了这个配置之后,Appdomain.CurrentDomain.UnhandledException 事件的 IsTerminating 就变成了 false 啦!也就是说,程序并不会因为这次的异常而崩溃退出。

既然你通过这个配置节点于微软达成了契约,你就需要好好地在 Appdomain.CurrentDomain.UnhandledException 事件中写好异常的恢复逻辑。如果不好好恢复,小心有些致命的异常会导致你的程序出现雪崩式的错误,最终 Windows 还是会通过 CorruptedStateException 把你干掉的!


参考资料


本文会经常更新,请阅读原文: https://walterlv.github.io/post/prevent-app-crash-by-background-thread.html ,以避免陈旧错误知识的误导,同时有更好的阅读体验。

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