设计模式中有一个模式叫做责任链模式（Chain of Responsibility），它的目的是将多个对象连成一条链，并沿着这条链传递该请求，直到有对象处理它为止，异常的传递处理也应该采用责任链模式。
上一个建议中我们提出了异常需要封转，但仅仅封转还是不够的，还需要传递异常。我们知道，一个系统友好性的标志是用户对该系统的“粘性”，粘性越高，系统越友好，粘性越低系统友好性越差，那问题是怎么提高系统的“粘性”呢？友好的界面和功能是一个方面，另外一方面就是系统出现非预期情况时的处理方式了。
比如，我们的JEE项目一般都有三层结构：持久层、逻辑层、展现层，持久层负责与数据库交互，逻辑层负责业务逻辑的实现，展现层负责UI数据的处理。有这样一个模块：用户第一次访问的时候，需要持久层从user.xml中读取信息，如果该文件不存在则提示用户创建之，那问题来了：如果我们直接把持久层的异常FileNotFoundException抛弃掉，逻辑层根本无从得知发生了何事，也就不能为展现层提供一个友好的处理结果了，最终倒霉的就是展现层：没有办法提供异常信息，只能告诉用户说“出错了，我也不知道出什么错了”——毫无友好性可言。
正确的做法是先封装，然后传递，过程如下：
（1）把FileNotFoundException封装为MyException。
（2）抛出到逻辑层，逻辑层根据异常代码（或者自定义的异常类型）确定后续处理逻辑，然后抛出到展现层。
（3）展现层自行决定要展现什么，如果是管理员则可以展现低层级的异常，如果是普通用户则展示封装后的异常。
明白了异常为什么要传递，那接着的问题就是如何传递了。很简单，使用异常链进行异常的传递，我们以IOException为例来看看是如何传递的，代码如下：
public class IOException extends Exception{
//定义异常原因
public IOException（String message）{
super（message）；
}
//定义异常原因，并携带原始异常
public IOException（String message, Throwable cause）{
super（message, cause）；
}
//保留原始异常信息
public IOException（Throwable cause）{
super（cause）；
}
}
在IOException的构造函数中，上一个层级的异常可以通过异常链进行传递，链中传递异常的代码如下所示：
try{
//Do Something
}catch（Exception e）{
throw new IOException（e）；
}
捕捉到Exception异常，然后把它转化为IOException异常并抛出（此种方式也叫作异常转译），调用者获得该异常后再调用getCause方法即可获得Exception的异常信息，如此即可方便地查找到产生异常的根本信息，便于解决问题。
结合上一个建议来看，异常需要封装和传递，我们在进行系统开发时不要“吞噬”异常，也不要“赤裸裸”地抛出异常，封装后再抛出，或者通过异常链传递，可以达到系统更健壮、友好的目的。