编写高质量代码改善C#程序的157个建议——建议63:避免“吃掉”异常
2015-08-17 21:26
465 查看
建议63:避免“吃掉”异常
嵌套异常是很危险的行为,一不小心就就会将异常堆栈信息,也就是真正的Bug出处隐藏起来。这还不是最严重的,最严重的就是“吃掉”异常,即捕获,然后不向上层throw。
避免“吃掉”异常,并不是说不应该“吃掉”异常,而是这里有个重要原则:该异常可被预见,并且通常情况它不能算是一个Bug。
想象你正在对上万份文件进行解密,这些文件来自不同的客户端,很有肯能存在文件被破坏的情况,你的目标是将解密出来的数据插入数据库。这个时候,你不得不忽略掉那些解密失败的文件,让整个过程进行下去。当然,记录日志时必要的,因为后期你可能对解密失败的文件做统一处理。
另外一种情况,可能连记录日志都不需要。在对上千个受控端进行控制的分布式系统中,控制端需要发布心跳数据来判断受控端的在线情况。通常的做法是维护一个型号量,如果在一个可接受的阻滞时间内(如500ms)心跳数据发送失败,那么控制端线程将不会收到信号,即可以判断受控端的短线状态。这种情况下对每次SocketException进行记录,通常是没有意义的。
如果你不知道如何处理一个异常,那么千万不要“吃掉”异常,如果你一不小心“吃掉”了一个本该往上传递的异常,那么就可能诞生一个Bug,而且,解决它会很费周折。
转自:《编写高质量代码改善C#程序的157个建议》陆敏技
嵌套异常是很危险的行为,一不小心就就会将异常堆栈信息,也就是真正的Bug出处隐藏起来。这还不是最严重的,最严重的就是“吃掉”异常,即捕获,然后不向上层throw。
避免“吃掉”异常,并不是说不应该“吃掉”异常,而是这里有个重要原则:该异常可被预见,并且通常情况它不能算是一个Bug。
想象你正在对上万份文件进行解密,这些文件来自不同的客户端,很有肯能存在文件被破坏的情况,你的目标是将解密出来的数据插入数据库。这个时候,你不得不忽略掉那些解密失败的文件,让整个过程进行下去。当然,记录日志时必要的,因为后期你可能对解密失败的文件做统一处理。
另外一种情况,可能连记录日志都不需要。在对上千个受控端进行控制的分布式系统中,控制端需要发布心跳数据来判断受控端的在线情况。通常的做法是维护一个型号量,如果在一个可接受的阻滞时间内(如500ms)心跳数据发送失败,那么控制端线程将不会收到信号,即可以判断受控端的短线状态。这种情况下对每次SocketException进行记录,通常是没有意义的。
如果你不知道如何处理一个异常,那么千万不要“吃掉”异常,如果你一不小心“吃掉”了一个本该往上传递的异常,那么就可能诞生一个Bug,而且,解决它会很费周折。
转自:《编写高质量代码改善C#程序的157个建议》陆敏技
相关文章推荐
- 正确 C# 未来的期望
- 第一个小练习,从基础重新来
- C#接口详解
- c# ComboBox简单用法
- 编写高质量代码改善C#程序的157个建议——建议62:避免嵌套异常
- 编写高质量代码改善C#程序的157个建议——建议61:避免在finally内撰写无效代码
- 如何在C#中的委托实现
- [转]C# Invoke的使用方法
- [转载]C#控制台应用程序里调用自己写的函数的方法
- C#查看各种变量的指针地址
- 编写高质量代码改善C#程序的157个建议——建议60:重新引发异常时使用Inner Exception
- C#方法的封装
- 转:C# DataGridView控件清空数据出错解决方法
- 编写高质量代码改善C#程序的157个建议——建议59:不要在不恰当的场合下引发异常
- C#读写文件
- c# 获取路径的几种方法
- 可视化对比十多种排序算法(C#版)
- C# 系统应用之TreeView控件 (一).显示树状磁盘文件目录及加载图标(转)
- C# 中的IOCP线程池
- C# 中的IOCP线程池