技巧：当不能抛出异常时

核心提示： 清单 4 并没有消除出现 I/O 错误的可能性，这一点无法做到，技巧：当不能抛出异常时(5)，因为这里的代码无力提供这样的功能，但是，从而允许抛出异常，同时又不会使数据结构处于可能受损害的、中间的状态，可以将这个问题交给更合适的地方来处理， 避免问题前面提到的方法有点复杂

清单 4 并没有消除出现 I/O 错误的可能性。这一点无法做到，因为这里的代码无力提供这样的功能。但是，可以将这个问题交给更合适的地方来处理。

避免问题

前面提到的方法有点复杂，所以我建议另一种方法：不使用内置的 compare() 函数或 Collections.sort()。使用这样的函数也许比较方便，但是不适合当前情况。Comparable 和 Comparator 是为确定的、可预测的比较操作而设计的。一旦 I/O 不再符合这种情况，很可能常用的算法和接口变得不适用。即使勉强可以使用，其效率也极其低下。

例如，假设不是按标准路径来比较文件，而是按内容来比较文件。对于所比较的两个文件，每个比较操作都需要读文件的内容 — 甚至可能是完整的内容。这样一来，高效的算法会想要尽量减少读的次数，并且可能会想缓存每次读的结果 — 或者，如果文件较大，则可能缓存每个文件的 hashcode — 而不是每次比较时重新读每个文件。同样，您会想到首先填充一个比较键列表，然后进行排序，而不是进行内联排序。

可以想象定义一个单独的、并行的 IOComparator 接口，该接口抛出必要的异常，如清单 5 所示：

清单 5. 独立的 IOComparator 接口

import　java.io.IOException;　
　
public　interface　IOComparator<T>　{　
　
　　int　compare(T　o1,　T　o2)　throws　IOException;　
　　　
}

然后基于这个类定义一个单独的、相近实用程序树，由它对集合的临时副本进行必要的操作，从而允许抛出异常，同时又不会使数据结构处于可能受损害的、中间的状态。例如，清单 6 提供了一个基本的冒泡排序：

清单 6. 用冒泡算法对文件排序