利用Java 1.4的异常链表

不幸的是，当错误突然出现的时候，这种良好的封装就会被中止了。请看Listing A中的例子，我们从例子中可以看出，当状态正常的情况下，Scheduler对象不关心Task对象是怎样把值返回到getDuration的，然而，运行一旦出错，当Scheduler甚至还没意识到IO正在运行的时候，Scheduler便突然从DownloadTask转向了javalang JOException。

在Listing B中，我们可以清楚地看到，初始化程序是解决这个问题的一个方法。Task把异常转换成Exception的一个子集，Scheduler对这样的子集是非常熟悉的。这样，取代了正在进行的Scheduler对javaio.JOException反复研究的过程，调度程序创造了一个TaskException，在它的帮助下Scheduler知道怎样对TaskExceptio进行自如的处理。

这种解决方法的缺点在于IOException开始整个混合过程的能力丧失了。它已经被Task对象破坏并且被TaskException所取代。这就允许清理机制通过Scheduler作额外的清理工作，但是不帮助开发人员调试后期的错误。

Java 1.4 之前

Java 1.4被公布之前，你有三种方法来解决上述情况。第一，你可以通过IOExption所有中间过程到达它的顶部，并且在堆栈的最顶端试图处理异常，而异常的类型实现并不知道，如Listing A所示。第二，你可以建立一个可扩充的链表，异常从始至终连接在这个连表上，如Listing B中的TaskException所示。第三，你可以创造你自己的Exception子集，来遍历整个树实现异常子集的连接。最后一种方法很好的解释了Henri Yandell的文章《高效处理Java异常的两种方法》中的理论。在上述观点中，第三种是最佳的选择，但是API技术的运用会妨碍你使用你自己的Exception子集，这个时候第三种方法就开始土崩瓦解了。

Java 1.4时代

幸运的是，Java 1.4不做任何妥协。现在java lang Throwable类，java.lang.Exception的基本类，有了自己的域，这个域可以用来把最初问题的重要细节连接到使用者或者日志文件中去。这个域机可以在Throwable构造器重构造也可以用预先设计的方法构造。以前，你知是简单的把Throwable累加成串，这样在构造器的参数列表中，就可以实现异常消息的通信。后来，你可以通过initCause来建立一个已经构造的Throwable构造器。

这里有一个相应的获得方法getCaus，当printStackTrace已经被改变成为深度连表的时候， getCau 的使用还不是十分普遍。这种方法允许开发人员在他们调试程序过程中，他们的设计还没有改变的情况下，使用好的封装。

在Listing C中，我们可以看到我们的Scheduler/Task机制的改变是利用了Java 1.4的异常链表。当TaskException在顶端被过滤时，IOException作为根结点仍然是可利用的。在1.4工具箱的异常链表中，不再有对溢出的处理。