異常處理

概述

異常處理，是編程語言或計算機硬件裡的一種機制，用于處理軟件或信息系統中出現的異常狀況（即超出程序正常執行流程的某些特殊條件）。

各種編程語言在處理異常方面具有非常顯着的不同點（錯誤檢測與異常處理區别在于：錯誤檢測是在正常的程序流中，處理不可預見問題的代碼，例如一個調用操作未能成功結束）。某些編程語言有這樣的函數：當輸入存在非法數據時不能被安全地調用，或者返回值不能與異常進行有效的區别。例如，C語言中的atoi函數（ASCII串到整數的轉換）在輸入非法時可以返回0。在這種情況下編程者需要另外進行錯誤檢測（可能通過某些輔助全局變量如C的errno），或進行輸入檢驗（如通過正則表達式），或者共同使用這兩種方法。

通過異常處理，我們可以對用戶在程序中的非法輸入進行控制和提示，以防程序崩潰。

從進程的視角，硬件中斷相當于可恢複異常，雖然中斷一般與程序流本身無關。

從子程序編程者的視角，異常是很有用的一種機制，用于通知外界該子程序不能正常執行。如輸入的數據無效（例如除數是0），或所需資源不可用（例如文件丢失）。如果系統沒有異常機制，則編程者需要用返回值來标示發生了哪些錯誤。

基本模型

一種稱為"終止模型"(它是Java與C++所支持的模型).在這種模型中,将假設錯誤非常關鍵,将以緻于程序無法返回到異常發生的地方繼續執行.一旦異常被抛出,就表明錯誤已無法挽回,也不能回來繼續執行.

另一種稱為"恢複模型".意思是異常處理程序的工作是修正錯誤,然後重新嘗試調動出問題的方法,并認為第二次能成功.

對于恢複模型,通常希望異常被處理之後能繼續執行程序.在這種情況下,抛出異常更像是對方法的調用--可以在Java裡用這種方法進行配置,以得到類似恢複的行為.(也就是說,不是抛出異常,而是調用方法修正錯誤.)或者,把try塊放在while循環裡,這樣就可以不斷的進入try塊,直到得到滿意的結果.

雖然恢複模型開始顯得很吸引人,并且人們使用的操作系統也支持恢複模型的異常處理,但程序員們最終還是轉向了使用類似"終止模型"的代碼.因為:處理程序必須關注異常抛出的地點,這勢必要包含依賴于抛出位置的非通用性代碼.這增加了代碼編寫和維護的困難,對于異常可能會從許多地方抛出的大型程序來說,更是如此.

下面我寫的一個簡單的例子VC++6.0下通過

#include

usingnamespacestd;

classError

public:

virtualvoidshow()=0;

classDenoError:publicError

public:

voidshow()

cout<<"分母不可以為0!"<

voidmain()

inta,b;

cin>>a>>b;

try

DenoErrore;

if(b==0)

throwe;

intc=a/b;

cout<

catch(DenoError&e)

e.show();

處理方法

php異常

擴展php内置的異常處理類

用戶可以用自定義的異常處理類來擴展php内置的異常處理類。以下的代碼說明了在内置的異常處理類中，哪些屬性和方法在子類中是可訪問和可繼承的。譯者注：以下這段代碼隻為說明内置異常處理類的結構，它并不是一段有實際意義的可用代碼。

例子20-2.内置的異常處理類

如果使用自定義的類來擴展内置異常處理類，并且要重新定義構造函數的話，建議同時調用parent::__construct()來檢查所有的變量是否已被賦值。當對象要輸出字符串的時候，可以重載__toString()并自定義輸出的樣式。

例子20-3.擴展php内置的異常處理類

code}]:{$this->message}/n";}publicfunctioncustomFunction(){echo"ACustomfunctionforthistypeofexception/n";}}/***創建一個用于測試異常處理機制的類*/classTestException{public$var;constTHROW_NONE=0;constTHROW_CUSTOM=1;constTHROW_DEFAULT=2;function__construct($avalue=self::THROW_NONE){switch($avalue){caseself::THROW_CUSTOM://抛出自定義異常thrownewMyException('1isaninvalidparameter'5);break;caseself::THROW_DEFAULT://抛出默認的異常thrownewException('2isntallowedasaparameter'6);break;default://沒有異常的情況下，創建一個對象$thisvar=$avalue;break;}}}

Java異常處理

你覺得自己是一個Java專家嗎?北京海澱甲骨文學習中心幫你全面掌握了Java的異常處理機制?在下面這段代碼中，你能夠迅速找出異常處理的六個問題嗎?

作為一個Java程序員，你至少應該能夠找出兩個問題。但是，如果你不能找出全部六個問題，請繼續閱讀本文。

本文讨論的不是Java異常處理的一般性原則，因為這些原則已經被大多數人熟知。我們要做的是分析各種可稱為“反例”(anti-pattern)的違背優秀編碼規範的常見壞習慣，幫助讀者熟悉這些典型的反面例子，從而能夠在實際工作中敏銳地察覺和避免這些問題。

反例之一：丢棄異常

代碼：12行-15行。

這段代碼捕獲了異常卻不作任何處理，可以算得上Java編程中的殺手。從問題出現的頻繁程度和禍害程度來看，它也許可以和C/C++程序的一個惡名遠播的問題相提并論?不檢查緩沖區是否已滿。如果你看到了這種丢棄(而不是抛出)異常的情況，可以百分之九十九地肯定代碼存在問題(在極少數情況下，這段代碼有存在的理由，但最好加上完整的注釋，以免引起别人誤解)。

這段代碼的錯誤在于，異常(幾乎)總是意味着某些事情不對勁了，或者說至少發生了某些不尋常的事情，我們不應該對程序發出的求救信号保持沉默和無動于衷。調用一下printStackTrace算不上“處理異常”。不錯，調用printStackTrace對調試程序有幫助，但程序調試階段結束之後，printStackTrace就不應再在異常處理模塊中擔負主要責任了。

丢棄異常的情形非常普遍。打開JDK的ThreadDeath類的文檔，可以看到下面這段說明：“特别地，雖然出現ThreadDeath是一種‘正常的情形’，但ThreadDeath類是Error而不是Exception的子類，因為許多應用會捕獲所有的Exception然後丢棄它不再理睬。”這段話的意思是，雖然ThreadDeath代表的是一種普通的問題，但鑒于許多應用會試圖捕獲所有異常然後不予以适當的處理，所以JDK把ThreadDeath定義成了Error的子類，因為Error類代表的是一般的應用不應該去捕獲的嚴重問題。可見，丢棄異常這一壞習慣是如此常見，它甚至已經影響到了Java本身的設計。

那麼，應該怎樣改正呢?主要有四個選擇：

1、處理異常。針對該異常采取一些行動，例如修正問題、提醒某個人或進行其他一些處理，要根據具體的情形确定應該采取的動作。再次說明，調用printStackTrace算不上已經“處理好了異常”。

2、重新抛出異常。處理異常的代碼在分析異常之後，認為自己不能處理它，重新抛出異常也不失為一種選擇。

3、把該異常轉換成另一種異常。大多數情況下，這是指把一個低級的異常轉換成應用級的異常(其含義更容易被用戶了解的異常)。

4、不要捕獲異常。

結論一：既然捕獲了異常，就要對它進行适當的處理。不要捕獲異常之後又把它丢棄，不予理睬。

反例之二：不指定具體的異常

代碼：12行。

許多時候人們會被這樣一種“美妙的”想法吸引：用一個catch語句捕獲所有的異常。最常見的情形就是使用catch(Exceptionex)語句。但實際上，在絕大多數情況下，這種做法不值得提倡。為什麼呢?

要理解其原因，我們必須回顧一下catch語句的用途。catch語句表示我們預期會出現某種異常，而且希望能夠處理該異常。異常類的作用就是告訴Java編譯器我們想要處理的是哪一種異常。由于絕大多數異常都直接或間接從java.lang.Exception派生，catch(Exceptionex)就相當于說我們想要處理幾乎所有的異常。

再來看看前面的代碼例子。我們真正想要捕獲的異常是什麼呢?最明顯的一個是SQLException，這是JDBC操作中常見的異常。另一個可能的異常是IOException，因為它要操作OutputStreamWriter。顯然，在同一個catch塊中處理這兩種截然不同的異常是不合适的。如果用兩個catch塊分别捕獲SQLException和IOException就要好多了。這就是說，catch語句應當盡量指定具體的異常類型，而不應該指定涵蓋範圍太廣的Exception類。

另一方面，除了這兩個特定的異常，還有其他許多異常也可能出現。例如，如果由于某種原因，executeQuery返回了null，該怎麼辦?答案是讓它們繼續抛出，即不必捕獲也不必處理。實際上，我們不能也不應該去捕獲可能出現的所有異常，程序的其他地方還有捕獲異常的機會?直至最後由JVM處理。

結論二：在catch語句中盡可能指定具體的異常類型，必要時使用多個catch。不要試圖處理所有可能出現的異常。

反例之三：占用資源不釋放

代碼：3行-11行。

異常改變了程序正常的執行流程。這個道理雖然簡單，卻常常被人們忽視。如果程序用到了文件、Socket、JDBC連接之類的資源，即使遇到了異常，也要正确釋放占用的資源。為此，Java提供了一個簡化這類操作的關鍵詞finally。

finally是樣好東西：不管是否出現了異常，Finally保證在try/catch/finally塊結束之前，執行清理任務的代碼總是有機會執行。遺憾的是有些人卻不習慣使用finally。

當然，編寫finally塊應當多加小心，特别是要注意在finally塊之内抛出的異常?這是執行清理任務的最後機會，盡量不要再有難以處理的錯誤。

結論三：保證所有資源都被正确釋放。充分運用finally關鍵詞。

反例之四：不說明異常的詳細信息

代碼：3行-11行。

仔細觀察這段代碼：如果循環内部出現了異常，會發生什麼事情?我們可以得到足夠的信息判斷循環内部出錯的原因嗎?不能。我們隻能知道當前正在處理的類發生了某種錯誤，但卻不能獲得任何信息判斷導緻當前錯誤的原因。

printStackTrace的堆棧跟蹤功能顯示出程序運行到當前類的執行流程，但隻提供了一些最基本的信息，未能說明實際導緻錯誤的原因，同時也不易解讀。

因此，在出現異常時，最好能夠提供一些文字信息，例如當前正在執行的類、方法和其他狀态信息，包括以一種更适合閱讀的方式整理和組織printStackTrace提供的信息。

結論四：在異常處理模塊中提供适量的錯誤原因信息，組織錯誤信息使其易于理解和閱讀。

反例之五：過于龐大的try塊

代碼：3行-11行。

經常可以看到有人把大量的代碼放入單個try塊，實際上這不是好習慣。這種現象之所以常見，原因就在于有些人圖省事，不願花時間分析一大塊代碼中哪幾行代碼會抛出異常、異常的具體類型是什麼。把大量的語句裝入單個巨大的try塊就象是出門旅遊時把所有日常用品塞入一個大箱子，雖然東西是帶上了，但要找出來可不容易。

一些新手常常把大量的代碼放入單個try塊，然後再在catch語句中聲明Exception，而不是分離各個可能出現異常的段落并分别捕獲其異常。這種做法為分析程序抛出異常的原因帶來了困難，因為一大段代碼中有太多的地方可能抛出Exception。

結論五：盡量減小try塊的體積。

反例之六：輸出數據不完整

代碼：7行-8行。

不完整的數據是Java程序的隐形殺手。仔細觀察這段代碼，考慮一下如果循環的中間抛出了異常，會發生什麼事情。循環的執行當然是要被打斷的，其次，catch塊會執行?就這些，再也沒有其他動作了。已經輸出的數據怎麼辦?使用這些數據的人或設備将收到一份不完整的(因而也是錯誤的)數據，卻得不到任何有關這份數據是否完整的提示。對于有些系統來說，數據不完整可能比系統停止運行帶來更大的損失。

較為理想的處置辦法是向輸出設備寫一些信息，聲明數據的不完整性;另一種可能有效的辦法是，先緩沖要輸出的數據，準備好全部數據之後再一次性輸出。

結論六：全面考慮可能出現的異常以及這些異常對執行流程的影響。

改寫後的代碼

根據上面的讨論，下面給出改寫後的代碼。也許有人會說它稍微有點啰嗦，但是它有了比較完備的異常處理機制。