如果你的程序抛了异常，你是怎么处理的呢？等待程序崩溃退出？还是进行补救？
如果是做 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 把你干掉的！