作者：運(yùn)氣
email: webmaster@chinaspx.com
日期：7/1/2001 10:10:46 PM
Java編程中的異常處理是一個(gè)很常見(jiàn)的話題了，幾乎任何一門(mén)介紹性的Java課程都會(huì)提到異常處理。不過(guò)，我認(rèn)為很多人其實(shí)并沒(méi)有真正掌握正確處理異常情況的方法和策略，最多也就不過(guò)了解個(gè)大概，知道點(diǎn)概念。本文就對(duì)三種不同程度和質(zhì)量的Java異常處理進(jìn)行了討論，所闡述的處理異常的方式按手法的高下分為：好，不好和惡劣三種。同時(shí)向你提供了一些解決這些問(wèn)題的技巧。 
好 
異常處理提供了處理程序錯(cuò)誤的統(tǒng)一機(jī)制。事實(shí)上，Java語(yǔ)言通過(guò)向調(diào)用者提出異常警告的方式而顯著地提升了軟件開(kāi)發(fā)中的異常處理能力。這種方式把Java語(yǔ)言中的“方法（method）”進(jìn)行了擴(kuò)展和增強(qiáng)，使之包括了自身的錯(cuò)誤條件。下面就讓我們看一個(gè)例子，這個(gè)例子說(shuō)明了這種情況。 
以下是FileInputStream構(gòu)造器之一的原型： 
public FileInputStream(String name) throws FileNotFoundException  
這個(gè)原型和C或者C++語(yǔ)言中的同類原形都不一樣，Java的方法和構(gòu)造器必須聲明他們?cè)诒徽{(diào)用時(shí)可能“扔出”的異常，采用的關(guān)鍵字就是“throws”。這種在方法原型中出現(xiàn)的異常提示增加了編程的可靠性。顯而易見(jiàn)，這種方式是向方法的調(diào)用者提示意了可能出現(xiàn)的異常條件，這樣調(diào)用者就可以對(duì)這些異常作出適當(dāng)?shù)南鄳?yīng)處理。 
以下代碼示意我們是如何捕獲并且處理FileNotFoundException 這一異常的： 
try 
 { 
 FileInputStream fis = new FileInputStream(args[0]);  
 // other code here ...  
 } catch (FileNotFoundException fnfe)  
 { 
 System.out.println("File: " + args[0] + " not found. Aborting.");  
 System.exit(1);  
 } 
Java異常處理還有其他一些優(yōu)秀的特性，這就是可檢查異常、用戶定義異常和在JDK 1.4中推出的新型Java記錄API（Java Logging API）。 
java.lang.Exception的所有子類都屬于可檢查異常。可檢查異常（checked exception）是扔出該異常的方法所必須提示的異常，這種異常必須被捕獲或者向調(diào)用者提示。 
用戶定義異常（User-defined exceptions）是定制的異常類，這種異常類擴(kuò)展了java.lang.Exception類。優(yōu)良的Java程序規(guī)定定制異常封裝、報(bào)告和處理他們自己獨(dú)有的情況。最新的Java記錄API（logging API）則可以集中記錄異常。 
不好 
Java異常處理不好的一面包括兩種情況：濫用非檢查異常（unchecked exceptions）和濫用catchall構(gòu)造器等。這兩種方式都使得問(wèn)題變得復(fù)雜起來(lái)。 
有一種類別的異常屬于RuntimeException的子類，這種異常不會(huì)受到編譯器的檢查。比如，NullPointerException和 ArrayStoreException就是這種類型異常的實(shí)例。程序員可以對(duì)RuntimeException進(jìn)行子類化以回避檢查異常的限制，從而便于產(chǎn)生這些異常的方法為其調(diào)用者所使用。專業(yè)的開(kāi)發(fā)團(tuán)隊(duì)?wèi)?yīng)當(dāng)只允許在很少的情況下才可以這樣做。第2種異常處理的陋習(xí)是catchall構(gòu)造器。所謂的“catchall 構(gòu)造器”就是一種異常捕獲代碼模塊，它可以處理所有扔給它的可能異常。 
以下是catchall處理器的實(shí)例： 
try 
 { 
 // code here with checked exceptions 
 } catch (Throwable t)  
 { 
 t.printStackTrace(); 
 } 
我得承認(rèn)，我自己在編寫(xiě)一般程序的時(shí)候就曾經(jīng)用過(guò)這種技術(shù)；但是，在編寫(xiě)關(guān)鍵程序的時(shí)候這種類型的構(gòu)造器一定要避免使用，除非他們被授權(quán)可以和中央錯(cuò)誤處理器聯(lián)合使用才可以這樣做。除此之外，catchall構(gòu)造器不過(guò)只是一種通過(guò)避免錯(cuò)誤處理而加快編程進(jìn)度的機(jī)制。 
異常處理的一個(gè)不足之處是難以采用優(yōu)良的錯(cuò)誤處理策略。從低容內(nèi)存狀態(tài)恢復(fù)、寫(xiě)入錯(cuò)誤和算法錯(cuò)誤等異常情況都不是輕易能得到解決的。你可以嘗試一下循環(huán)、垃圾收集和提醒用戶等常用技術(shù)來(lái)應(yīng)付以上的局面。 
惡劣 
和許多Java特性及其API類似，Java的異常處理機(jī)制也有“霸王硬上弓”類的滑稽錯(cuò)誤。比方說(shuō)，為了扔出某個(gè)異常竟然毫不猶豫地用“new”關(guān)鍵詞為其分配內(nèi)存就是這樣的例子。我自己不知道有多少次就因?yàn)榉噶诉@種錯(cuò)誤而在嚴(yán)肅的編譯器面前屢屢碰壁。在這種情況下，我們其實(shí)都是在伺候語(yǔ)言而不是讓語(yǔ)言為我們所用。 
在我編寫(xiě)的Java Pitfalls一書(shū)中探討了幾個(gè)異常處理方面的缺陷，比如處理OutOfMemoryErrors就是其一。這一處理過(guò)程是：使用finally模塊關(guān)閉文件，解析異常以得到出現(xiàn)問(wèn)題的方法和代碼行。在這一過(guò)程之內(nèi)最大的缺陷是需要捕獲OutOfMemoryError，而這一異常卻并不是可檢查異常！想想看，內(nèi)存耗盡是相當(dāng)常見(jiàn)的情況。任何與內(nèi)存使用狀態(tài)緊密相關(guān)的程序都應(yīng)當(dāng)捕獲和處理這一錯(cuò)誤。 
最后，讓我們考慮兩個(gè)尚不屬于Java異常處理機(jī)制的特性。第一，目前的情況是，在你成功地處理了異常之后你沒(méi)有辦法回到你剛才離開(kāi)的地方。而C語(yǔ)言下的setjmp() 和longjmp()函數(shù)則可以實(shí)現(xiàn)這一特性，Java理應(yīng)有這兩個(gè)函數(shù)的對(duì)應(yīng)版本，而我們也應(yīng)該可以用“resume”關(guān)鍵詞實(shí)現(xiàn)它。 
第二個(gè)沒(méi)有實(shí)現(xiàn)的特性是全局異常處理器，對(duì)比物就是C++語(yǔ)言中的set_new_handler()。比方說(shuō)，在編程的時(shí)候，即便OutOfMemoryError異常比java.lang.Error 的子類更常見(jiàn)，但我們也可以針對(duì)OutOfMemoryError異常而采用全局處理器，這樣的效果會(huì)比對(duì)其采用通常的可檢查異常要好得多。如果你覺(jué)得對(duì)這些特性非常在意，那么你可以在Java Developer Connection那里提出自己的建議：在Java平臺(tái)內(nèi)增加這些特性吧！