Java實用技巧：當不能拋出checked異常時
checked異常的一個問題是，有時候不允許拋出這樣的異常。特別是，如果要覆蓋超類中聲明的方法，或者實現接口中聲明的方法，而那個方法沒有聲明任何checked異常，那么新的實現也不能聲明checked異常。
因此必須預先處理異常，另外，可以將異常轉換為運行時異常，或者繞過它而不處理它。但是，應該這樣做嗎，這其中是否隱藏著錯誤？
相關文章推薦：Java三種常見異常及解決 如何更合理的利用Java中的異常拋出
問題
只要看一個例子，問題就清楚了。假設有一個File對象的List，需要按它們的標準路徑以字典順序排序。所謂標準路徑，是指在解析別名、符號鏈接和/../及/./之后得到的完整絕對路徑。本地方法使用一個比較器，如清單1所示：
- 清單1.按標準路徑比較兩個文件
- importjava.io.File;
- importjava.io.IOException;
- importjava.util.ArrayList;
- importjava.util.Collections;
- importjava.util.Comparator;
- publicclassFileComparatorimplementsComparator<File>{
- publicintcompare(Filef1,Filef2){
- returnf1.getCanonicalPath().compareTo(f2.getCanonicalPath());
- }
- publicstaticvoidmain(String[]args){
- ArrayList<File>files=newArrayList<File>();
- for(Stringarg:args){
- files.add(newFile(arg));
- }
- Collections.sort(files,newFileComparator());
- for(Filef:files){
- System.out.println(f);
- }
- }
- }
不幸的是，該代碼不能通過編譯。問題在于，getCanonicalPath()方法拋出一個IOException，因為它需要訪問文件系統。通常，當使用checked異常時，可以使用以下兩種方法之一：
1.將出錯的代碼包裝在一個try塊中，并捕捉拋出的異常。
2.聲明包裝方法（本例為compare()）也拋出IOException。
通常，至于選擇何種方法，取決于是否能在拋出異常時合理地處理異常。如果能，那么使用try-catch塊。如果不能，那么聲明包裝方法本身拋出異常。不幸的是，這兩種技巧對于本例都不管用。在compare()方法中無法合理地處理IOException。從技術上講，似乎可以做到—即返回0、1或-1，如清單2所示：
- 清單2.拋出異常時返回一個默認值
- publicintcompare(Filef1,Filef2){
- try{
- returnf1.getCanonicalPath().compareTo(f2.getCanonicalPath());
- }
- catch(IOExceptionex){
- return-1;
- }
- }
然而，這違反了compare()方法的約定，因為它不是一個穩定的結果。對于相同的對象，前后兩次調用可能產生不同的結果。如果使用這個比較器來排序，那么意味著最終列表沒有被正確排序。所以現在試試第2個選項—聲明compare()拋出IOException：
- publicintcompare(Filef1,Filef2)throwsIOException{
- returnf1.getCanonicalPath().compareTo(f2.getCanonicalPath());
- }
這也不能通過編譯。因為checked異常是方法簽名的一部分，在覆蓋方法時，不能增加checked異常，就像不能改變return類型一樣。那么最后還剩下一個折中選項：在compare()中捕捉異常，將它轉換成運行時異常，然后拋出運行時異常，如清單3所示：
- 清單3.將checked異常轉換成運行時異常
- publicintcompare(Filef1,Filef2){
- try{
- returnf1.getCanonicalPath().compareTo(f2.getCanonicalPath());
- }
- catch(IOExceptionex){
- thrownewRuntimeException(ex);
- }
- }
不幸的是，雖然這樣可以通過編譯，但是這種方法也不管用，其原因較為微妙。Comparator接口定義一個合約（請參閱參考資料）。這個合約不允許該方法拋出運行時異常（防止因違反泛型類型安全而成為調用代碼中的bug）。使用這個比較器的方法合理地依靠它來比較兩個文件，而不拋出任何異常。它們沒有準備好處理compare()中意外出現的異常。
正是由于這個微妙的原因，讓運行時異常成為代碼要處理的外部狀況是一個壞主意。這樣只是逃避問題，并沒有真正處理問題。不處理異常所帶來的不良后果仍然存在，包括毀壞數據和得到不正確的結果。
這樣便陷入了困境。既不能在compare()內真正有效地處理異常，又不能在compare()之外處理異常。還剩下什么地方可以處理異常—System.exit()？惟一正確的辦法是完全避免這種困境。幸運的是，至少有兩種方法可以做到這一點。
#p#
將問題一分為二
第一種辦法是將問題一分為二。比較本身不會導致異常。比較的只是字符串而已。通過標準路徑將文件轉換成字符串才會導致異常。如果將可能拋出異常的操作與不會拋出異常的操作分開，那么問題就更容易處理了。也就是說，首先將所有文件對象轉換為字符串，然后通過字符串比較器（甚至可以通過java.lang.String的自然排序）對字符串排序，最后使用排序后的字符串列表對原始的文件列表排序。這種方法不太直接，但是優點是在列表被改變之前就拋出IOException。如果出現異常，它只會出現在預先設計好的地方，不會造成損害，調用代碼可以指定如何處理異常。清單4對此作了演示：
- 清單4.先讀取，然后排序
- importjava.io.File;
- importjava.io.IOException;
- importjava.util.ArrayList;
- importjava.util.Collections;
- importjava.util.HashMap;
- publicclassFileComparator{
- privatestaticArrayList<String>getCanonicalPaths(ArrayList<File>files)
- throwsIOException{
- ArrayList<String>paths=newArrayList<String>();
- for(Filefile:files)paths.add(file.getCanonicalPath());
- returnpaths;
- }
- publicstaticvoidmain(String[]args)throwsIOException{
- ArrayList<File>files=newArrayList<File>();
- for(Stringarg:args){
- files.add(newFile(arg));
- }
- ArrayList<String>paths=getCanonicalPaths(files);
- //tomaintaintheoriginalmapping
- HashMap<String,File>map=newHashMap<String,File>();
- inti=0;
- for(Stringpath:paths){
- map.put(path,files.get(i));
- i++;
- }
- Collections.sort(paths);
- files.clear();
- for(Stringpath:paths){
- files.add(map.get(path));
- }
- }
- }
清單4并沒有消除出現I/O錯誤的可能性。這一點無法做到，因為這里的代碼無力提供這樣的功能。但是，可以將這個問題交給更合適的地方來處理。
避免問題
前面提到的方法有點復雜，所以我建議另一種方法：不使用內置的compare()函數或Collections.sort()。使用這樣的函數也許比較方便，但是不適合當前情況。Comparable和Comparator是為確定的、可預測的比較操作而設計的。一旦I/O不再符合這種情況，很可能常用的算法和接口變得不適用。即使勉強可以使用，其效率也極其低下。
例如，假設不是按標準路徑來比較文件，而是按內容來比較文件。對于所比較的兩個文件，每個比較操作都需要讀文件的內容—甚至可能是完整的內容。這樣一來，高效的算法會想要盡量減少讀的次數，并且可能會想緩存每次讀的結果—或者，如果文件較大，則可能緩存每個文件的hashcode—而不是每次比較時重新讀每個文件。同樣，您會想到首先填充一個比較鍵列表，然后進行排序，而不是進行內聯排序。可以想象定義一個單獨的、并行的IOComparator接口，該接口拋出必要的異常，如清單5所示：
- 清單5.獨立的IOComparator接口
- importjava.io.IOException;
- publicinterfaceIOComparator<T>{
- intcompare(To1,To2)throwsIOException;
- }
然后基于這個類定義一個單獨的、相近實用程序樹，由它對集合的臨時副本進行必要的操作，從而允許拋出異常，同時又不會使數據結構處于可能受損害的、中間的狀態。例如，清單6提供了一個基本的冒泡排序：
- 清單6.用冒泡算法對文件排序
- importjava.io.IOException;
- importjava.util.ArrayList;
- importjava.util.List;
- publicclassIOSorter{
- publicstatic<T>voidsort(List<T>list,IOComparator<?superT>comparator)
- throwsIOException{
- List<T>temp=newArrayList<T>(list.size());
- temp.addAll(list);
- bubblesort(temp,comparator);
- //copybacktooriginallistnowthatnoexceptionshavebeenthrown
- list.clear();
- list.addAll(temp);
- }
- //ofcourseyoucanreplacethiswithabetteralgorithmsuchasquicksort
- privatestatic<T>voidbubblesort(List<T>list,IOComparator<?superT>comparator)
- throwsIOException{
- for(inti=1;i<list.size();i++){
- for(intj=0;j<list.size()-i;j++){
- if(comparator.compare(list.get(j），list.get(j+1))>0){
- swap(list,j);
- }
- }
- }
- }
- privatestatic<T>voidswap(List<T>list,intj){
- Ttemp=list.get(j);
- list.set(j,list.get(j+1));
- list.set(j+1,temp);
- }
- }
這不是唯一的方法。為了清晰，清單6有意模仿已有的Collections.sort()方法；但是，也許更有效的方法是返回一個新的列表，而不是直接修改舊列表，以防在修改列表時拋出異常所帶來的損害。
#p#
最終，您實際上承認并著手處理可能出現的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異常，而這又是不允許的—因而抑制本不該抑制的異常—那么回過頭來，重新組織一下，考慮為什么一開始要覆蓋那個方法。很可能，您本應該采取完全不同的方式。
【編輯推薦】
