WPF异常处理
一、WPF中的未捕获异常(UnhandledException)
首先,我们当然是要求应用程序开发人员,尽可能地在程序可能出现异常的地方都去捕捉异常,使用try…catch的方式。但是总是有一些意外的情况可能会发生,这就导致会出现所谓的“未捕获异常(UnhandledException)”。对于这一类异常,如果我们没有一个合适的策略进行处理,则当其发生的时候,会给用户带来不太好的使用体验。例如下面这样:
用户看到这个窗口的时候,其实一般只能点击Close the prograrm按钮。也就是说,这种情况下会导致用户无法继续使用这个程序,而且他们还得不到任何具体的消息:到底发生了什么事情了?除非他们去查看Windows的事件日志。(但一般的用户是不太会这个操作的)
我们可以看到在Windows事件日志中,会有两个具体的事件。首先是一个.NET Runtime的事件:
然后是一个Application Error的事件:
通常来说,这样的用户体验有值得改进的地方。我们虽然不能防止异常的产生,但是当意外发生的时候,我们应该要以更好地方式地通知到用户,或者尽可能地不要影响用户当前的操作。
在WPF这种应用程序中,会有两大类未处理异常:一类是在UI线程抛出来的,例如点击了用户界面上面的某个控件,然后执行某个代码的时候,遇到了异常;另一类是非UI线程跑出来的,例如在一个多线程的程序里面,工作线程的代码遇到了异常。
对于UI线程的未处理异常,我们可以通过监控下面Application.Current.DispatcherUnhandledException 事件来处理。
对于非UI线程抛出的未处理异常,我们需要监控另外一个AppDomain.CurrentDomain.UnhandledException事件来处理。
// 避免多次添加事件处理
Application.Current.DispatcherUnhandledException -= AppOnDispatcherUnhandledException;
AppDomain.CurrentDomain.UnhandledException -= CurrentDomainUnhandledException;
Application.Current.DispatcherUnhandledException += AppOnDispatcherUnhandledException;
AppDomain.CurrentDomain.UnhandledException += CurrentDomainUnhandledException;
1、未捕获UI异常(Application.Current.DispatcherUnhandledException )
/// <summary>
/// UI线程抛出全局异常事件处理。
/// </summary>
private static void AppOnDispatcherUnhandledException(object sender, DispatcherUnhandledExceptionEventArgs e)
{
MessageBox.Show("我们很抱歉,当前应用程序遇到一些问题,该操作已经终止,请进行重试,如果问题继续存在,请联系管理员.", "意外的操作", MessageBoxButton.OK, MessageBoxImage.Information);//这里通常需要给用户一些较为友好的提示,并且后续可能的操作
e.Handled = true;//使用这一行代码告诉运行时,该异常被处理了,不再作为UnhandledException抛出了。
}
2、未捕获非UI异常(AppDomain.CurrentDomain.UnhandledException)
/// <summary>
/// 非UI线程抛出全局异常事件处理。
/// </summary>
private static void CurrentDomainUnhandledException(object sender, UnhandledExceptionEventArgs e)
{
MessageBox.Show("我们很抱歉,当前应用程序遇到一些问题,该操作已经终止,请进行重试,如果问题继续存在,请联系管理员.", "意外的操作", MessageBoxButton.OK, MessageBoxImage.Information);
}
令人不解的是,这个事件中没有和前面那个事件一样的e.Handled参数,就是说,虽然这样是可以捕捉到非UI线程的异常,而且也可以进行相应的处理,但是应用程序还是会退出,也就是说这个异常还是被当作是未处理异常继续汇报给Runtime。
为了改进这一点,我们可以通过修改配置文件来实现。
二、配置 legacyUnhandledExceptionPolicy
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
把你干掉的!