gaoxiang

专注于.NET技术

博客园 首页 新随笔 联系 订阅 管理

1.异常处理相对于返回错误代码的一个最大优点在于,异常可以被自动传递,这样,在编程时异常更加难以被忽视。

2.通常,只在最上层(一般是UI层)捕捉异常。如果要在其它层捕捉异常,除非是下列情况之一:
 (1)能够处理该异常,或者
 (2)能够忽略该异常,或者
 (3)需要转换该异常为其它特定异常后抛出新异常

3.UI层捕获异常后,可以
 (1)将无关紧要的异常忽略。
 (2)将异常转换为错误信息展现给用户。
 (3)如果是重大异常,可以考虑终止应用程序。

4.最上层(一般是UI层)不得抛出新的异常;最上层需要捕捉所有异常,否则异常会直接导致程序终止,这将是非常不好的用户体验。

5.可以在非最上层抛出自定义异常。如果是自定义异常,请保证其是可序列化的,并且保证其实现了Exception的三个构造函数。

6.异常的抛出与截获需要很多的cpu时间,请谨慎的使用异常。

7.在可能抛出异常的地方,如果需要,请确保使用finally进行资源清理,而无论此处是否捕捉了异常。

8.在一个catch块中的代码都应该至少部分地处理了所捕捉的异常。否则,就不要使用catch块。

9.从构造函数中抛出异常。
  因为构造函数没有返回值,所以没有简单的方法来想构造函数的调用者发出构造失败的信号,这时便可以通过抛出异常来做到。比如构造参数与指定条件不符时,就抛出一个异常。 

10.在以上前提的保证下,可以在非最上层使用AOP截获(intercept)异常而进行日志记录,这样通过日志记录,我们可以了解系统的  运行状态。记不起在哪里看到过这样一句话:在软件实现中,异常和日志都是重要的质量保证手段,异常和日志总是同时出现的。
  可以说,异常是日志记录的重要/主要组成部分。

Feedback

# re: 异常处理经验谈   回复   

2005-09-10 17:02 by 暴风雨
为什么要保证自定义异常是可序列化的呢?

# re: 异常处理经验谈   回复   

2005-09-10 17:07 by zhuweisky
这样可以保证异常可以通过Remoting进行传播。

# re: 异常处理经验谈   回复   

2005-09-10 18:03 by 生活、工作
无非就是这四种处理措施:
截断传播路径。
包装成自定义异常。
替换成预定义异常。
处理掉。

尽可能在最低级别处理错误。
避免通过异常处理机制将较低级别抽象公开给较高级别。
如果您必须使异常沿栈上移,那么应将较低级别异常转化为对于处理层而言有一定意义的异常。

# re: 异常处理经验谈   回复   

2005-09-10 18:05 by 生活、工作
尽可能在最低级别处理错误。不是只在最上层(一般是UI层)捕捉异常。

# re: 异常处理经验谈   回复   

2005-09-10 22:15 by zhuweisky
to 生活、工作:
绝大多数情况下,即使是在异常出现的地方也不知道该如何处理,比如网络连接突然断开导致数据库访问失败,那么数据层该如何处理该异常了?返回一个false给上一层吗?这又回到了我上一篇文章谈到的问题了。请指教:)

# re: 异常处理经验谈   回复   

2005-09-11 01:27 by yicone
THANKS.
前两天刚刚有人对我传授了这方面的一些经验,你的文章使我再次加深对这个问题的认识。

个人认为:“请保证其是可序列化的”、“使用AOP截获(intercept)异常”这类句子
会吓到初学者的(如我这般),觉得“异常”很高深。还是麻烦在原文中稍加说明一下^_^
(我有空先去查查AOP吧,还不知道它和异常在一起使用,对它一点都不了解呢)

# re: 异常处理经验谈   回复   

2005-09-11 19:32 by 蛙蛙池塘
这才是真真的好贴子,一看楼主就是奋斗在编程第一线的战士,赞一个,希望能看到你更好的指导性的文章,对偶们菜鸟简直就是久旱逢甘霖呀。要让我总结出这么几条,肯定得花半年以上的时间。以后我在写类库的时候可以好好回味一下你这篇文章了。

# re: 异常处理经验谈   回复   

2005-09-12 09:14 by jinta2001
各位大大有没有碰到过UC层通过“反射”调用其他类或者方法,如果被调用的类或者方法出现异常,UI层收到的错误信息不会是原始的错误信息,而是什么调用错误
posted on 2006-05-18 15:25  S孤单一吻S  阅读(322)  评论(0编辑  收藏  举报