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
无非就是这四种处理措施：
截断传播路径。
包装成自定义异常。
替换成预定义异常。
处理掉。
尽可能在最低级别处理错误。
避免通过异常处理机制将较低级别抽象公开给较高级别。
如果您必须使异常沿栈上移，那么应将较低级别异常转化为对于处理层而言有一定意义的异常。
截断传播路径。
包装成自定义异常。
替换成预定义异常。
处理掉。
尽可能在最低级别处理错误。
避免通过异常处理机制将较低级别抽象公开给较高级别。
如果您必须使异常沿栈上移，那么应将较低级别异常转化为对于处理层而言有一定意义的异常。
to 生活、工作:
绝大多数情况下，即使是在异常出现的地方也不知道该如何处理，比如网络连接突然断开导致数据库访问失败，那么数据层该如何处理该异常了？返回一个false给上一层吗？这又回到了我上一篇文章谈到的问题了。请指教：）
绝大多数情况下，即使是在异常出现的地方也不知道该如何处理，比如网络连接突然断开导致数据库访问失败，那么数据层该如何处理该异常了？返回一个false给上一层吗？这又回到了我上一篇文章谈到的问题了。请指教：）
THANKS.
前两天刚刚有人对我传授了这方面的一些经验，你的文章使我再次加深对这个问题的认识。
个人认为：“请保证其是可序列化的”、“使用AOP截获(intercept)异常”这类句子
会吓到初学者的（如我这般），觉得“异常”很高深。还是麻烦在原文中稍加说明一下^_^
(我有空先去查查AOP吧，还不知道它和异常在一起使用，对它一点都不了解呢)
前两天刚刚有人对我传授了这方面的一些经验，你的文章使我再次加深对这个问题的认识。
个人认为：“请保证其是可序列化的”、“使用AOP截获(intercept)异常”这类句子
会吓到初学者的（如我这般），觉得“异常”很高深。还是麻烦在原文中稍加说明一下^_^
(我有空先去查查AOP吧，还不知道它和异常在一起使用，对它一点都不了解呢)
这才是真真的好贴子，一看楼主就是奋斗在编程第一线的战士，赞一个，希望能看到你更好的指导性的文章，对偶们菜鸟简直就是久旱逢甘霖呀。要让我总结出这么几条，肯定得花半年以上的时间。以后我在写类库的时候可以好好回味一下你这篇文章了。
