这不是唯一的方法。为了清晰，清单6有意模仿已有的Collections.sort()方法；但是，也许更有效的方法是返回一个新的列表，而不是直接修改旧列表，以防在修改列表时抛出异常所带来的损害。
最终，您实际上承认并着手处理可能出现的I/O错误，而不是逃避它，您甚至可以做更高级的错误修正。例如，IOComparator也许不会被一次I/O错误难倒—因为很多I/O问题是暂时的—可以重试几次，如清单7所示：
|
这种技巧不能解决常规的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异常，而这又是不允许的—因而抑制本不该抑制的异常—那么回过头来，重新组织一下，考虑为什么一开始要覆盖那个方法。很可能，您本应该采取完全不同的方式。
相关链接：
