技巧：当不能抛出异常时

核心提示： 这不是唯一的方法，为了清晰，技巧：当不能抛出异常时(7)，清单 6 有意模仿已有的 Collections.sort() 方法；但是，也许更有效的方法是返回一个新的列表，考虑为什么一开始要覆盖那个方法，很可能，而不是直接修改旧列表，以防在修改列表时抛出异常所带来的损害

这不是唯一的方法。为了清晰，清单 6 有意模仿已有的 Collections.sort() 方法；但是，也许更有效的方法是返回一个新的列表，而不是直接修改旧列表，以防在修改列表时抛出异常所带来的损害。

最终，您实际上承认并着手处理可能出现的 I/O 错误，而不是逃避它，您甚至可以做更高级的错误修正。例如，IOComparator 也许不会被一次 I/O 错误难倒 — 因为很多 I/O 问题是暂时的 — 可以重试几次，如清单 7 所示：

清单 7. 如果一开始不成功，再试几次（但是别试太多次）

import　java.io.File;　
import　java.io.IOException;　
　
public　class　CanonicalPathComparator　implements　IOComparator<File>　{　
　
　　@Override　
　　public　int　compare(File　f1,　File　f2)　throws　IOException　{　
　　　　for　(int　i　=　0;　i　<　3;　i++)　{　
　　　　　　try　{　
　　　　　　　　return　f1.getCanonicalPath().compareTo(f2.getCanonicalPath());　
　　　　　　}　
　　　　　　catch　(IOException　ex)　{　
　　　　　　　　continue;　
　　　　　　}　
　　　　}　
　　　　//　last　chance　
　　　　return　f1.getCanonicalPath().compareTo(f2.getCanonicalPath());　　
　　}　
　
}

这种技巧不能解决常规的 Comparator 的问题，因为必须重试无数次才能避免抛出异常，而且很多 I/O 问题并不是暂时性的。

checked 异常是坏主意吗？

如果 java.io.IOException 是运行时异常，而不是 checked 异常，问题是不是有所改观？答案是否定的。如果 IOException 扩展 RuntimeException 而不是 java.lang.Exception，那么更容易编写出有 bug 的、不正确的代码，这种代码忽略了真正可能发生的 I/O 错误，而在运行时出人意料地失败。

然而，编写正确的、有准备并且能够处理 I/O 错误的代码并不会更容易。是的，相对于不会出现意外 I/O 错误，不需要为此做准备的情况，这种方法更加复杂。但是，从 Java 语言中消除 checked 异常无助于我们实现那样的理想情况。I/O 错误和其他环境问题是常态，积极准备比视而不见要好得多。

总之，checked 异常作为方法签名的一部分并非没有道理。当您发现自己想要从一个方法抛出一个 checked 异常，而这又是不允许的 — 因而抑制本不该抑制的异常 — 那么回过头来，重新组织一下，考虑为什么一开始要覆盖那个方法。很可能，您本应该采取完全不同的方式。