摘要：catch(exception &ex)是捕獲所有標(biāo)準(zhǔn)庫定義中的類std:exception;catch(...)則是捕獲所有的異常。

1.簡介

???異常是由語言提供的運(yùn)行時刻錯誤處理的一種方式。提到錯誤處理，即使不提到異常，你大概也已經(jīng)有了豐富的經(jīng)驗，但是為了可以清楚的看到異常的好處，我們還是不妨來回顧一下常用的以及不常用的錯誤處理方式。

C++異常之網(wǎng)絡(luò)知識

1.1常用的錯誤處理方式

返回值。我們常用函數(shù)的返回值來標(biāo)志成功或者失敗，甚至是失敗的原因。但是這種做法最大的問題是如果調(diào)用者不主動檢查返回值也是可以被編譯器接受的，你也奈何不了他:)這在C++中還導(dǎo)致另外一個問題，就是重載函數(shù)不能只有不同的返回值，而有相同的參數(shù)表，因為如果調(diào)用者不檢查返回值，則編譯器會不知道應(yīng)該調(diào)用哪個重載函數(shù)。當(dāng)然這個問題與本文無關(guān)，我們暫且放下。只要謹(jǐn)記返回值可能被忽略的情況即可。

全局狀態(tài)標(biāo)志。例如系統(tǒng)調(diào)用使用的errno。返回值不同的是，全局狀態(tài)標(biāo)志可以讓函數(shù)的接口（返回值、參數(shù)表）被充分利用。函數(shù)在退出前應(yīng)該設(shè)置這個全局變量的值為成功或者失敗（包括原因），而與返回值一樣，它隱含的要求調(diào)用者要在調(diào)用后檢查這個標(biāo)志，這種約束實(shí)在是同樣軟弱。全局變量還導(dǎo)致了另外一個問題，就是多線程不安全：如果多個線程同時為一個全局變量賦值，則調(diào)用者在檢查這個標(biāo)志的時候一定會非常迷惑。如果希望線程安全，可以參照errno的解決辦法，它是線程安全的。

1.2不常用的處理方式

setjmp()/longjmp()。可以認(rèn)為它們是遠(yuǎn)程的goto語句。根據(jù)我的經(jīng)驗，它們好象確實(shí)不常被用到，也許是多少破壞了結(jié)構(gòu)化編程風(fēng)格的原因吧。在C++中，應(yīng)該是更加的不要用它們，因為致命的弱點(diǎn)是longjmp()雖然會unwindingstack（這個詞后面再說），但是不會調(diào)用棧中對象的析構(gòu)函數(shù)--夠致命吧。對于不同的編譯器，可能可以通過加某個編譯開關(guān)來解決這個問題，但太不通用了，會導(dǎo)致程序很難移植。

1.3異常

現(xiàn)在我們再來看看異常能解決什么問題。對于返回值和errno遇到的尷尬，對異常來說基本上不存在，如果你不捕獲(catch)程序中拋出的異常，默認(rèn)行為是導(dǎo)致abort()被調(diào)用，程序被終止(coredump)。因此你的函數(shù)如果拋出了異常，這個函數(shù)的調(diào)用者或者調(diào)用者的調(diào)用者，也就是在當(dāng)前的callstack上，一定要有一個地方捕獲這個異常。而對于setjmp()/longjmp()帶來的棧上對象不被析構(gòu)的問題對異常來說也是不存在的。那么它是否破壞了結(jié)構(gòu)化（對于OOparadigms，也許應(yīng)該說是破壞了流程？）呢？顯然不是，有了異常之后你可以放心的只書寫正確的邏輯，而將所有的錯誤處理歸結(jié)到一個地方，這不是更好么？

綜上所述，在C++中大概異常可以全面替代其它的錯誤處理方式了，可是如果代碼中到處充斥著try/throw/catch也不是件好事，欲知異常的使用技巧，請保持耐心繼續(xù)閱讀:)

2.異常的語法

在這里我們只討論一些語法相關(guān)的問題。

2.1try

try總是與catch一同出現(xiàn)，伴隨一個try語句，至少應(yīng)該有一個catch()語句。try隨后的block是可能拋出異常的地方。

2.2catch

catch帶有一個參數(shù)，參數(shù)類型以及參數(shù)名字都由程序指定，名字可以忽略，如果在catch隨后的block中并不打算引用這個異常對象的話。參數(shù)類型可以是build-intype，例如int,long, char等，也可以是一個對象，一個對象指針或者引用。如果希望捕獲任意類型的異常，可以使用“...”作為catch的參數(shù)。

catch不一定要全部捕獲tryblock中拋出的異常，剩下沒有捕獲的可以交給上一級函數(shù)處理。

2.3throw

throw后面帶一個類型的實(shí)例，它和catch的關(guān)系就象是函數(shù)調(diào)用，catch指定形參，throw給出實(shí)參。編譯器按照catch出現(xiàn)的順序以及catch指定的參數(shù)類型確定一個異常應(yīng)該由哪個catch來處理。

throw不一定非要出現(xiàn)在try隨后的block中，它可以出現(xiàn)在任何需要的地方，只要最終有catch可以捕獲它即可。即使在catch隨后的block中，仍然可以繼續(xù)throw。這時候有兩種情況，一是throw一個新類型的異常，這與普通的throw一樣。二是要rethrow當(dāng)前這個異常，在這種情況下，throw不帶參數(shù)即可表達(dá)。例如：

try{
???...
}
catch(int){
??? throwMyException("hello exception");??? //拋出一個新的異常
}
catch(float){
???throw;??????????????????// 重新拋出當(dāng)前的浮點(diǎn)數(shù)異常
}

2.4函數(shù)聲明

還有一個地方與throw關(guān)鍵字有關(guān)，就是函數(shù)聲明。例如：

void foo() throw (int);?????//只能拋出int型異常
voidbar() throw ();???????? //不拋出任何異常
voidbaz();?????????????????// 可以拋出任意類型的異常或者不拋出異常

如果一個函數(shù)的聲明中帶有throw限定符，則在函數(shù)體中也必須同樣出現(xiàn)：

void foo() throw (int)
{
???...
}

這里有一個問題，非常隱蔽，就是即使你象上面一樣編寫了foo()函數(shù)，指定它只能拋出int異常，而實(shí)際上它還是可能拋出其他類型的異常而不被編譯器發(fā)現(xiàn)：

void foo() throw (int)
{
???throw float;???? // 錯誤！異常類型錯誤！會被編譯器指出
???...
??? baz();??????????// 正確！baz()可能拋出非int異常而編譯器又不能發(fā)現(xiàn)！
}

voidbaz()
{
??? throw float;
}

這種情況的直接后果就是如果baz()拋出了異常，而調(diào)用foo()的代碼又嚴(yán)格遵守foo()的聲明來編寫，那么程序?qū)?/span>abort()。這曾經(jīng)讓我很惱火，認(rèn)為這種機(jī)制形同虛設(shè)，但是還是有些解決的辦法，請參照“使用技巧”中相關(guān)的問題。

3.異常使用技巧

3.1異常是如何工作的

為了可以有把握的使用異常，我們先來看看異常處理是如何工作的。

3.1.1unwinding stack

我們知道，每次函數(shù)調(diào)用發(fā)生的時候，都會執(zhí)行保護(hù)現(xiàn)場寄存器、參數(shù)壓棧、為被調(diào)用的函數(shù)創(chuàng)建堆棧這幾個對堆棧的操作，它們都使堆棧增長。每次函數(shù)返回則是恢復(fù)現(xiàn)場，使堆棧減小。我們把函數(shù)返回過程中恢復(fù)現(xiàn)場的過程稱為unwindingstack。

異常處理中的throw語句產(chǎn)生的效果與函數(shù)返回相同，它也引發(fā)unwindingstack。如果catch不是在throw的直接上層函數(shù)中，那么這個unwinding的過程會一直持續(xù)，直到找到合適的catch。如果沒有合適的catch，則最后std::unexpected()函數(shù)被調(diào)用，說明發(fā)現(xiàn)了一個沒想到的異常，這個函數(shù)會調(diào)用std::terminate()，這個terminate()調(diào)用abort()，程序終止(coredump)。

在“簡介”中提到的longjmp()也同樣會unwindingstack，但是這是一個C函數(shù)，它就象free()不會調(diào)用對象的析構(gòu)函數(shù)一樣，它也不知道在unwindingstack的過程中調(diào)用棧上對象的析構(gòu)函數(shù)。這是它與異常的主要區(qū)別。

3.1.2RTTI

在unwindingstack的過程中，程序會一直試圖找到一個“合適”的catch來處理這個異常。前面我們提到throw和catch的關(guān)系很象是函數(shù)調(diào)用和函數(shù)原型的關(guān)系，多個catch就好象一個函數(shù)被重載為可以接受不同的類型。根據(jù)這樣的猜測，好象找到合適的catch來處理異常與函數(shù)重載的過程中找到合適的函數(shù)原型是一樣的，沒有什么大不了的。但實(shí)際情況卻很困難，因為重載的調(diào)用在編譯時刻就可以確定，而異常的拋出卻不能，考慮下面的代碼：

void foo() throw (int)
{
???throw int;
}

void bar()
{
???try{
??????? foo();
???}
??? catch(int){
???????...
??? }
???catch(float){
??????? ...
???}
}

void baz()
{
???try{
??????? foo();
???}
??? catch(int){
???????...
??? }
???catch(float){
??????? ...
???}
}

foo()在兩個地方被調(diào)用，這兩次異常被不同的catch捕獲，所以在為throw產(chǎn)生代碼的時候，無法明確的指出要由哪個catch捕獲，也就是說，無法在編譯時刻確定。

仍然考慮這個例子，讓我們來看看既然不能在編譯時刻確定throw的去向，那么在運(yùn)行時刻如何確定。在bar()中，一列catch就象switch語句中的case一樣排列，實(shí)際上是一系列的判斷過程，依次檢查當(dāng)前異常的類型是否滿足catch指定的類型，這種動態(tài)的，在運(yùn)行時刻確定類型的技術(shù)就是RTTI(RuntimeTypeIdentification/Information)。深度探索C++對象模型[1]中提到，RTTI就是異常處理的副產(chǎn)品。關(guān)于RTTI又是一個話題，在這里就不詳細(xì)討論了。

3.2是否繼承std::exception？

是的。而且std::exception已經(jīng)有了一些派生類，如果需要可以直接使用它們，不需要再重復(fù)定義了。

3.3每個函數(shù)后面都要寫throw()?

盡管前面已經(jīng)分析了這樣做也有漏洞，但是它仍然是一個好習(xí)慣，可以讓調(diào)用者從頭文件得到非常明確的信息，而不用翻那些可能與代碼不同步的文檔。如果你提供一個庫，那么在庫的入口函數(shù)中應(yīng)該使用catch(...)來捕獲所有異常，在catch(...)中捕獲的異常應(yīng)該被轉(zhuǎn)換（rethrow）為throw列表中的某一個異常，這樣就可以保證不會產(chǎn)生意外的異常。

3.4guard模式

異常處理在unwindingstack的時候，會析構(gòu)所有棧上的對象，但是卻不會自動刪除堆上的對象，甚至你的代碼中雖然寫了delete語句，但是卻被throw跳過，導(dǎo)致內(nèi)存泄露，或者其它資源的泄露。例如：

void foo()
{
???...
??? MyClass * p = new MyClass();
???bar(p);
??? ...
??? deletep;?????? //如果bar()中拋出異常，則不會運(yùn)行到這里！
}

voidbar(MyClass * p)
{
??? throw MyException();
}

對于這種情況，C++提供了std::auto_ptr這個模板來解決問題。這個常被稱為“智能指針”的模板原理就是，將原來代碼中的指針用一個棧上的模板實(shí)例保護(hù)起來，當(dāng)發(fā)生異常unwindingstack的時候，這個模板實(shí)例會被析構(gòu)，而在它的析構(gòu)函數(shù)中，指針將被delete，例如：

void foo()
{
???...
??? std::auto_ptr<MyClass> p(newMyClass());
??? bar(p.get());
???...
??? // delete p;??????// 這句不再需要了
}

voidbar(MyClass * p)
{
??? throw MyException();
}

不論bar()是否拋出異常，只要p被析構(gòu)，內(nèi)存就會被釋放。

不光對于內(nèi)存，對于其他資源的管理也可以參照這個方法來完成。在ACE[2]中，這種方式被稱為Guard，用來對鎖進(jìn)行保護(hù)。

3.5構(gòu)造函數(shù)和析構(gòu)函數(shù)

構(gòu)造函數(shù)沒有返回值，很多地方都推薦通過拋出異常來通知調(diào)用者構(gòu)造失敗。這是肯定是個好的辦法，但是也不很完美。主要是因為在構(gòu)造函數(shù)中拋出異常并不會引發(fā)析構(gòu)函數(shù)的調(diào)用，例如：

class foo
{
public:
???~foo() {} // 這個函數(shù)將被調(diào)用
};

class bar
{
public:
???bar() { c_ = new char[10]; throw -1;}
??? ~bar() {delete c_;} // 這個函數(shù)不會被調(diào)用！
private:
???char * c_;
??? foo f_;
};

void baz()
{
???try{
??????? bar b;
???}
??? catch(int){
??? }
}

在這個例子中，bar的析構(gòu)函數(shù)不會被調(diào)用，但是盡管如此，foo的析構(gòu)函數(shù)還是可以被調(diào)用。危險的是在構(gòu)造函數(shù)中分配空間的c_，因為析構(gòu)函數(shù)沒有被調(diào)用而變成了leak。最好的解決辦法還是auto_ptr，使用auto_ptr后，bar類的聲明變成：

class bar
{
public:
???bar() { c_.reset(newchar[10]); throw -1;}
??? ~bar() { } // 不需要再deletec_了！
private:
??auto_ptr<char> c_;
???foo f_;
};

析構(gòu)函數(shù)中則不要拋出異常，這一點(diǎn)在ThinkingIn C++ Volume 2[3]中有明確表述。如果析構(gòu)函數(shù)中調(diào)用了可能拋出異常的函數(shù)，則應(yīng)該在析構(gòu)函數(shù)內(nèi)部catch它。

3.6什么時候使用異常

到現(xiàn)在為止，我們已經(jīng)討論完了異常的大部分問題，可以實(shí)際操作操作了。實(shí)際應(yīng)用中遇到的最讓我頭疼的問題就是什么時候應(yīng)該使用異常，是否應(yīng)該用異常全面代替“簡介”中提到的其它錯誤處理方式呢？

首先，不能用異常完全代替返回值，因為返回值的含義不一定只是成功或失敗，有時候是一個可選擇的狀態(tài)，例如：

if(customer->status() ==active){
??? ...
}
else{
???...
}

在這種情況下，不論返回值是什么，都是程序可以接受的正常的結(jié)果。而異常只能用來表達(dá)“異常”--也就是錯誤的狀態(tài)。這好象是顯而易見的事情，但是實(shí)際編程的過程中有很多更加模棱兩可的時候，遇到這樣的情況，首先要考慮的就是這個原則。

第二，看看在特定的情況下異常是否會發(fā)揮它的優(yōu)點(diǎn)，而這個優(yōu)點(diǎn)正好又不能使用其他技術(shù)達(dá)到（或者簡單的達(dá)到）。比如，如果你正在為電信公司寫一個復(fù)雜計費(fèi)邏輯，那么你當(dāng)然希望在整個計算費(fèi)用的過程中集中精力去考慮業(yè)務(wù)邏輯方面的問題，而不是到處需要根據(jù)當(dāng)前返回值判斷是否釋放前面步驟中申請的資源。這時候使用異常可以讓你的代碼非常清晰，即使你有100處申請資源的地方，只要一個地方集中釋放他們就好了。例如：

bool bar1();
boolbar2();
bool bar3();

bool foo()
{
???...
??? char * p1 = new char[10];
???...
??? if(!bar1()){
???????delete p1;
??????? returnfalse;
??? }
??? ...
???char * p2 = new char[10];
??? ...
???if(!bar2()){
??????? deletep1;????????????// 要釋放前面申請的所有資源
???????delete p2;
??????? returnfalse;
??? }
??? ...
???char * p3 = new char[10];
??? ...
???if(!bar2()){
??????? deletep1;????????????// 要釋放前面申請的所有資源
???????delete p2;
??????? deletep3;
??????? return false;
???}
}

這種流程顯然不如：

void bar1() throw(int);
voidbar2() throw(int);
void bar3() throw(int);

void foo() throw(int)
{
??? char * p1 = NULL;
???char * p2 = NULL;
??? char * p3 = NULL;
???try{
??????? char * p1 = newchar[10];
???????bar1();
??????? char * p2 = newchar[10];
???????bar2();
??????? char * p3 = newchar[10];
??????? bar3();
???}
??? catch(int){
???????delete p1;??????? //集中釋放資源
???????delete p2;
??????? deletep3;
??????? throw;
???}
}

第三，在ThinkingIn C++ Volume 2[3]中列了一個什么時候不應(yīng)該用，什么時候應(yīng)該用的表，大家可以參考一下。

最后，說一個與異常無關(guān)的東西，但也跟程序錯誤有關(guān)的，就是斷言(assert)，我在開發(fā)中使用了異常后，很快發(fā)現(xiàn)有的人將應(yīng)該使用assert處理的錯誤定義成了異常。這里稍微提醒一下assert的用法，非常簡單的原則：只有對于那些可以通過改進(jìn)程序糾正的錯誤，才可以用assert。返回值、異常顯然與其不在一個層面上，這是C的入門知識。

4 ??c++ 捕獲所有異常的寫法

????try
????{
????????device?=?createDevice(video::EDT_DIRECT3D9,
????????????core::dimension2d<u32>(512,?384));
????}
????catch?(...)
????{
????????device?=?0;
????}
????

===2013.1.9?根據(jù)zhouaihui1010?的指出修改=========================

上面這種異常捕獲方式，對于c++?除零錯誤，?內(nèi)存錯誤等異常無法捕獲。

除零錯誤，可以用signal函數(shù)處理硬件中斷信號來處理。

try-catch異常捕獲的兩種模式有關(guān)。同步模式和異步模式。其中前者不能捕獲內(nèi)存訪問錯誤，后者可以捕獲內(nèi)存訪問錯誤。?
/EHs是啟用同步模式。(同???/GX)???????
/EHa是起用異步模式。

VC的工程的調(diào)試版本缺省使用異步模式，工程的發(fā)布版本缺省使用同步模式。

實(shí)際上，win32開發(fā)中還有個Windows?SEH?結(jié)構(gòu)化異常。結(jié)構(gòu)化異常是Windows操作系統(tǒng)提供的與語言無關(guān)的異常處理機(jī)制，?SHE使用Win32API中的RaiseException()函數(shù)來拋出異常，在VC中使用關(guān)鍵字__try和關(guān)鍵字__except來捕獲，并用宏函數(shù)GetExceptionCode和GetExceptionInfo來獲取捕獲的異常由什么原因產(chǎn)生，和產(chǎn)生異常時環(huán)境狀態(tài)。__finally關(guān)鍵字保證無論是否發(fā)生異常，finally代碼段都會被執(zhí)行。

---------------------------------------------------

由上種種可以看出，c++由于比較接近底層，因此程序員在擁有更大自由度的同時，也需要處理更多的問題。

異常的定義

如果一個位置所發(fā)生的事情最終能夠被正確的處理并使得程序如期正常運(yùn)行，那么這件事情又怎么能被認(rèn)為是一個錯誤呢？”事實(shí)上，我們把這類異常事件（或簡稱異常）以及用來處理這類事件的語言機(jī)制一起成為異常處理（exception handling）。

C++異常之我的見解

標(biāo)準(zhǔn)的c++庫里包含<exception><stdexcept>

其中<exception>之定義了最基本的exception類

<stdexcept>中定義了從exception類繼承出來的其他一般異常類

--------------------------------------------------------------------------------
exception??? ?? ?? ?? ???由C++標(biāo)準(zhǔn)庫為所有拋出異常的類提供的類庫.使用what()函數(shù)可以取得exception對象初始化時被設(shè)置的可選字符串.
logic_error??? ?? ?? ?? ???從exception類派生.報告程序邏輯錯誤,通過檢查代碼,能夠發(fā)現(xiàn)這類錯誤.
------------------------------------------------------------------------------
runtime_error??? ?? ?? ?從exception類派生.報告運(yùn)行時錯誤,只有在程序運(yùn)行時,這類錯誤才可能被檢測到.
ios::failure??? ?? ?? ?? ???從exception類派生,沒有子類從logic_error派生的異常類:
domian_error??? ?? ?? ?? ???報告違反了前置條件
invalid_argument??? ?? ???表明拋出這個異常的函數(shù)接收到了一個無效的參數(shù)
length_error??? ?? ?? ?? ???表明程序試圖產(chǎn)生一個長度大于npos的對象
out_of_range??? ?? ?? ?? ???報告一個參數(shù)越界錯誤
-------------------------------------------------------------------------
bad_cast??? ?? ?? ?? ?? ???? ?拋出這個異常的原因是在運(yùn)行時類型識別(runtimetype identification)中發(fā)現(xiàn)程序執(zhí)行了????????????????????????一個無效的動態(tài)類型轉(zhuǎn)換(dynamic_cast)表達(dá)式
------------------------------------------------------------------------------
bad_typeid??? ?? ?? ?? ???當(dāng)表達(dá)式typeid(*p)中的參數(shù)p是一個空指針時拋出這個異常
--------------------------------------------------------------------------------從runtime_error派生的異常--------------------------------------------------------------------------------
range_error??? ?? ?? ?? ???報告違反了后置條件.
----------------------------------------------------------------------------
overflow_error??? ?? ?? ?? ???報告一個算術(shù)溢出錯誤
-----------------------------------------------------------------------------
bad_alloc??? ?? ?? ?? ?? ???? ?報告一個失敗的存儲分配

本質(zhì)

異常類雖然多但是,只是定義一種規(guī)范而已,類本身沒有和類名相對應(yīng)任何處理語句,他就像書的目錄一樣,只是起到一種歸類的作用本身沒有任何內(nèi)容.

真正實(shí)現(xiàn)的異常的地方是在一個獨(dú)立的框架或平臺中通過判斷不同的條件throw出來的,throw的信息可以穿越多層函數(shù)最后返回到catch的地方.

但是有一點(diǎn)需要主意有時在面向過程的編程(如c++的c編程風(fēng)格)中他會打亂程序的順序,有可能是某些狀態(tài)無效,所以在處理完異常后需要重新設(shè)置狀態(tài).

還有一點(diǎn)就是通過沒有經(jīng)過驗證需進(jìn)一步來驗證

A--?B(B繼承自A)

Throw了B類的異常

再catchA類異常的時候可以捕獲B類的異常

所以在CATCH的時候要把子類放在前面?????

作者：張笑猛

原文出處：http://objects.nease.net/

轉(zhuǎn)載于:https://www.cnblogs.com/catkins/p/5270610.html

總結(jié)

以上是生活随笔為你收集整理的C++异常(exception)第一篇--综合讲解的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。