技巧：当不能抛出异常时

核心提示： 清单 3. 将 checked 异常转换成运行时异常publicintcompare(Filef1,Filef2){try{returnf1.getCanonicalPath().compareTo(f2.getCanonicalPath());}catch(IOExceptionex){thr

清单 3. 将 checked 异常转换成运行时异常

public　int　compare(File　f1,　File　f2)　{　
　　try　{　
　　　　return　f1.getCanonicalPath().compareTo(f2.getCanonicalPath());　
　　}　
　　catch　(IOException　ex)　{　
　　　　throw　new　RuntimeException(ex);　
　　}　
}

不幸的是，虽然这样可以通过编译，但是这种方法也不管用，其原因较为微妙。Comparator 接口定义一个合约。这个合约不允许该方法抛出运行时异常（防止因违反泛型类型安全而成为调用代码中的 bug）。使用这个比较器的方法合理地依靠它来比较两个文件，而不抛出任何异常。它们没有准备好处理 compare() 中意外出现的异常。

正是由于这个微妙的原因，让运行时异常成为代码要处理的外部状况是一个坏主意。这样只是逃避问题，并没有真正处理问题。不处理异常所带来的不良后果仍然存在，包括毁坏数据和得到不正确的结果。

这样便陷入了困境。既不能在 compare() 内真正有效地处理异常，又不能在 compare() 之外处理异常。还剩下什么地方可以处理异常 — System.exit()？ 惟一正确的办法是完全避免这种困境。幸运的是，至少有两种方法可以做到这一点。

将问题一分为二

第一种办法是将问题一分为二。比较本身不会导致异常。比较的只是字符串而已。通过标准路径将文件转换成字符串才会导致异常。如果将可能抛出异常的操作与不会抛出异常的操作分开，那么问题就更容易处理了。也就是说，首先将所有文件对象转换为字符串，然后通过字符串比较器（甚至可以通过 java.lang.String 的自然排序）对字符串排序，最后使用排序后的字符串列表对原始的文件列表排序。这种方法不太直接，但是优点是在列表被改变之前就抛出 IOException。如果出现异常，它只会出现在预先设计好的地方，不会造成损害，调用代码可以指定如何处理异常。清单 4 对此作了演示：