异常处理2个基本原则:
1.不要“封杀”所有异常
2.应该友好地向用户显示异常信息
第一个原则:不要“封杀”所有异常
举例说明:
try
{
DoSomething();
}
catch( Exception ex )
{
MessageBox.Show( ex.Message);
}
上面这段代码,就是把所有异常都“封杀”掉了,直接把异常显示到了UI上,导致程序永远“无异常”。
为什么说不合理?Exception,异常,顾名思义,就是出现了我们开发者无法预见的问题。既然是无法预见,我们就应该用日志记录下来,并传递到我们开发者的后台,方便我们改进程序;如果采用这种“封杀”手段,我们永远无法获得程序出现的“无法预见”的问题。
我们根据异常系统记录的异常,进行问题诊断,确定具体导致此异常的原因,最后的结果有2种:
1.程序修改后,不会再导致异常
2.由于某些操作,一定会导致一个“特定”的异常
对于2,我们举例说明,如果用户使用系统导出Excel文件,保存时选择一个正在打开的文件,那么就会导致System.IO.IOException。那么我们下面这种写法是可以的:
try
{
DoSomething();
}
catch( System.IO.IOException ex )
{
MessageBox.Show( "文件被占用,请检查是否已经处于打开状态。");
}
也就是说,我们可以捕获一个“已知”的异常,并用合适的语言呈现给UI。
第二个原则:应该友好地向用户显示异常信息
举个例子,大家在用软件(无论是我们自己单位开发的还是别的单位开发的)是否有看到过“NullReferenceException: 未将对象引用设置到对象的实例”,心理感觉是不是觉得糟糕透了?如果一个不懂程序的人,看到了了这个异常,更是莫名其妙,“对象?引用?实例?”
对于这种未知的异常,用友好的方式提醒用户,并由用户确认是否发送给我们。
下文我将结合我们公司的异常系统,来讲讲在派尔公司应该怎么做。
|