引 言

　　C++的異常機制為我們提供了更好的解決方法。異常處理的基本思想是：當出現錯誤時拋出一個異常，希望它的調用者能捕獲并處理這個異常。如果調用者也不能處理這個異常，那么異常會傳遞給上級調用，直到被捕獲處理為止。如果程序始終沒有處理這個異常，最終它會被傳到C++運行環境，運行環境捕獲后通常只是簡單地終止這個程序。異常機制使得正常代碼和錯誤處理代碼清晰地劃分開來，程序變得非常干凈并且容易維護。

　　但是如何合理地使用異常機制來達到預期的效果呢?MISRA C++給出了一些推薦的規則，幫助程序員更加合理、可靠地實現異常機制。下面將結合這些規則對異常機制進行簡單的探討。

　　1 在恰當的場合使用恰當的特性

　　MISRA C++對異常的第1條規則就是：

　　規則15-0-1(不容討論)：異常機制只能用來處理錯誤。

　　異常處理的本質是控制流程的轉移，但異常機制是針對錯誤處理的，僅在代碼可能出現異常的情況下使用，不能用來實現普通的流程轉移。

　　例如：

?

　　語法不會阻止你這樣做，但殺雞焉用牛刀。這樣不但會降低程序的可讀性，也會帶來更大的開銷。實際上，用一個簡單的if語句就可以實現上述邏輯。同樣，出于程序流程的清晰性考慮的還有：

　　規則15-0-3(強制)：不允許通過goto或者switch語句跳轉到try或catch語句塊內。

　　2 正確地拋出異常

　　什么時候，什么地方，拋出什么樣的異常，都是需要仔細考慮的。MISRA C++對此也作了相關規定。首先，來看一下拋出異常對象的類型中有哪些需要注意的地方。規則15-0-2(推薦)：拋出的異常對象不應該是指針類型。

　　如果拋出的異常對象是個指針類型，指向的是動態創建的對象，那么這個對象應該由哪個函數來負責銷毀，什么時候銷毀，都很不清楚。比如說，如果是在堆中建立的對象，那通常必須刪除，否則會造成資源泄漏;如果不是在堆中建立的對象，通常不能刪除，否則程序的行為將不可預測。

　　規則15-1-2(強制)：不能顯式地把NULL作為異常對象拋出。

　　因為throw(NULL)=tbrow(0)，因此NULL會被當作整型捕獲，而不是空指針常量，這可能與程序員的預期不一致。

　　通常，很多函數都是基于function-try-block結構的，即函數體整個包含在一個函數try塊中。而函數能拋出什么類型的異常對象，有以下規定：

　　規則15-5-2(強制)：如果一個函數聲明時指定了具體的異常類型，那么它只能拋出指定類型的異常。

　　規則15-4-1(強制)：如果一個函數聲明時指定了異常的類型，那么在其他編譯單元里該函數的聲明必須有同樣的指定。

　　函數的代碼結構如下：返回值類型函數名(形參表)throw(類型名表){函數體}

　　如果函數在聲明時沒有異常規范，那么它可以拋出任意類型的異常對象;如果異常類型為空，則表示不拋出任何類型異常。注意這兩者之間的區別，前者指沒有throw(類型名表)語句，而后者有throw(類型名表)，只是類型名表為空。但如果聲明時指定了異常的類型，那么它只能拋出指定類型的異常。

　　另外，函數原型中的異常聲明要與實現中的異常聲明一致，否則會引起異常沖突。由于異常機制是在運行出現異常時才發揮作用的，因此如果函數的實現中拋出了沒有在其異常聲明列表中列出的異常，編譯器也許不能檢查出來。當拋出一個未在其異常聲明列表里的異常類型時，unexpected()函數會被調用，默認會導致std::bad_exception類型的異常被拋出。如果std::bad_exception不在異常聲明列表里，又會導致terminate()被調用，從而導致程序結束。

　　對于什么時候能拋出異常，則有以下規定：

　　規則15-3-1(強制)：異常只能在初始化之后而且程序結束之前拋出。

　　在執行main函數體之前，是初始化階段，構造和初始化靜態對象;在main函數返回后，是終止階段，靜態對象被銷毀。在這兩個階段中如果拋出異常，會導致程序以不定的方式終止(這依賴于具體的編譯器)。例如：

?

　　在這個例子中，catch塊只能捕獲上面try塊中的異常。如果在對象c的構造函數或析構函數中拋出異常，并不能被main里的catch塊捕獲，而且會導致程序終止。

　　除了上述規則，還有以下兩個規則需要注意：

　　規則15-1-1(強制)：throw語句中的表達式本身不能引發新的異常。

　　如果在構造異常對象，或者計算賦值表達式時引發新的異常，那么新的異常會在本來要拋出的異常之前被拋出，這與程序員的預期不一致。

　　規則15-1-3(強制)：空的throw語句只能出現在catch語句塊中。

　　空的throw用來將捕獲的異常再拋出，可以實現多個處理程序問異常的傳遞。然而，如果在catch語句外用，由于沒有捕獲到異常，也就沒有東西可以再拋出，這樣會導致程序以不定的方式終止(這依賴具體的編譯器)。

　　3 合理地處理異常

　　由于后面的討論多處涉及到“棧展開”這個概念，這里先解釋一下?！皸Ｕ归_”是異常機制中一個重要的過程：在逐層查找用來處理異常的catch子句時，因為異常而退出復合語句和函數定義，這個過程被稱作“棧展開”。隨著棧的展開，在退出的復合語句和函數定義中聲明的局部變量的生命期也結束，而且這些局部類對象的析構函數也會被調用，這樣能保證內存空間得到合理回收。棧展開的概念對于理解后面的內容很重要，我們通過一個具體例子進一步闡述。

?

　　當異常發生時，在函數調用鏈中逐層查找該異常的catch子句。在棧展開過程中函數foo()首先被檢查到，因為產生異常的語句沒有被放在try塊中，所以不會在：foo()中查找針對該異常的catch子句。棧展開過程繼續向上遍歷函數調用鏈到達調用foo()的函數。然而在foo()帶著這個未處理的異常退出之前，棧展開過程會銷毀foo()中所有在異常產生之前被創建的局部類對象。結果就是：o1、o2的析構函數被調用，o3已經“死亡”，而o4還沒“出生”。

　　顧名思義，“異?！本褪浅绦蜻\行出現了非預期的情況，或者說錯誤。因此，出現異常必須有針對地處理。對此，MISRA C++首先有如下規定：

　　規則15-3-4(強制)：所有可能的流程中顯式拋出來的異常都應該有一個類型兼容的處理程序。

　　規則15-3-2(推薦)：至少要有一個處理程序來處理所有其他未針對處理的異常。

　　如果程序拋出一個沒有被處理的異常，程序會終止，而終止前調用棧有沒有被“展開”，動態對象能不能被析構，這些都依賴于編譯器。上面兩條規則規定了：不但預期拋出的異常要進行處理，其他可能被拋出的異常也要有相應的處理措施。請注意規則15-3-4中“類型兼容”的字眼，C++有非常靈活的類型兼容規則，尤其對于類。例如當異常對象是派生類時，“兼容類型”可以是派生類，也可以是基類。后面我們還會具體討論這個問題。

　　一個try塊后可以有多個catch塊來捕獲不同的異常。當出現異常時，catch處理程序按照其在try塊后出現的順序被逐個檢查，只要找到一個匹配的異常類型，后面的異常處理都被忽略。因此，catch處理程序出現的順序很重要。

　　規則15-3-6(強制)：若一個try-catch語句塊有多個處理程序，或者一個派生類和其部分或全部基類的function-try-block塊有多個處理程序，處理程序的順序應該是先派生類后基類。

　　規則15-3-7(強制)：若一個try-catch語句塊或者function-try-block塊有多個處理程序時，catch(…)處理程序(捕獲所有異常)應該放在最后。

　　這是因為根據類型兼容規則，異常對象為派生類時可以被針對基類的處理程序所捕獲。如果針對基類的處理程序放在前面，后面針對派生類的處理程序就不會被執行到。同理，catch(…)處理程序能捕獲所有類型的異常，在其后面所有的異常處理程序都不會被執行到。

　　根據上述規則，典型的try-catch的結構示例如下：

?

　　細心的讀者也許會發現，上面例子中是通過引用來捕獲類的對象。當異常對象類型為某個類時，有3種方式傳遞到catch子句里：指針、傳值和引用。也許大家首先想到的是指針，指針的確是效率很高的工具，而且不涉及到對象拷貝。但不要忘了，前面的規則15-0-2中明確指出，拋出的異常對象不應該是指針類型。而對于傳值和引用，在MISRA C++中給出的規定是：通過引用捕獲異常。

　　規則15-3-5(強制)：若異常對象為類的對象時，應該通過引用來捕獲。

　　通過值傳遞，不但會增加拷貝對象的開銷，而且還會出現“退化”問題。所謂“退化”是指：如果異常對象是一個派生類對象，但被作為基類捕獲，那么只有基類的函數(包括虛函數)能被調用，派生類中增加的數據成員都不能被訪問。通過引用捕獲則沒有這個問題。下面的例子具體地說明了“退化”問題：

?

?

　　鑒于類的構造函數和析構函數的特殊性，還有兩點需要注意。

　　規則15-3-3(強制)：如果類的構造函數和析構函數是function-try-block結構的，在catch處理程序中不能引用該類或其基類的非靜態成員。

　　這種行為的后果是不定的。比如說，當構造對象分配內存時拋出了異常，這時該對象本身還不存在，訪問其成員也就出錯。相反，在析構函數里，可能在異常處理程序執行前該對象已被成功銷毀了，也就無從訪問其成員了。而類的靜態成員則沒有上述問題。

　　規則15-5-1(強制)。類的析構函數退出后不能還有未處理的異常。

　　當異常拋出時，會進行棧展開。如果在某個析構過程中引發沒有被處理的異常，程序將會以不定的方式終止。析構函數拋出異常的問題在很多C++的書中都有討論，概括來說：析構函數應盡可能地避免拋出異常，如果的確無法避免，則析構函數自己應該包含處理所有可能拋出的異常的代碼。

　　4 小 結

　　異常機制是C++嶄新而高級的特性之一。與其他C++特性一樣，C++標準并沒有規定應該如何來實現異常機制，這依賴于具體的編譯器。異常機制是有代價的，它會增加代碼大小和運行開銷。以VC++為例，異常處理是通過在函數調用棧里增加許多相關的數據結構來實現的，感興趣的讀者可以查看相關資料，這里不再進一步討論;而且異常處理是在操作系統的協助下，由C++編譯器和運行時異常處理庫共同完成的。如何合理地使用異常機制來提高程序的健壯性，MISRA C++給出了一些規范，但具體還需要程序員反復斟酌，甚至需要多次實驗。