Java实用技巧：当不能抛出checked异常时(3)

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

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

importjava.io.File;

importjava.io.IOException;

publicclassCanonicalPathComparatorimplementsIOComparator<File>

{

@Override publicintcompare(Filef1,Filef2)throwsIOException

{

for(inti=0;i<3;i++)

{

try

{

returnf1.getCanonicalPath().compareTo(f2.getCanonicalPath());

}

catch(IOExceptionex)

{

continue;

}

//lastchance returnf1.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异常，而这又是不允许的—因而抑制本不该抑制的异常—那么回过头来，重新组织一下，考虑为什么一开始要覆盖那个方法。很可能，您本应该采取完全不同的方式

补充：软件开发 , Java ,