摘要：catch(exception &ex)是捕獲所有標准庫定義中的類std:exception;catch(...)則是捕獲所有的異常。
1.簡介
異常是由語言提供的運行時刻錯誤處理的一種方式。提到錯誤處理，即使不提到異常，你大概也已經有了豐富的經驗，但是為了可以清楚的看到異常的好處，我們還是不妨來回顧一下常用的以及不常用的錯誤處理方式。
1.1常用的錯誤處理方式
返回值。我們常用函數的返回值來標志成功或者失敗，甚至是失敗的原因。但是這種做法最大的問題是如果調用者不主動檢查返回值也是可以被編譯器接受的，你也奈何不了他:)這在C++中還導致另外一個問題，就是重載函數不能只有不同的返回值，而有相同的參數表，因為如果調用者不檢查返回值，則編譯器會不知道應該調用哪個重載函數。當然這個問題與本文無關，我們暫且放下。只要謹記返回值可能被忽略的情況即可。
全局狀態標志。例如系統調用使用的errno。返回值不同的是，全局狀態標志可以讓函數的接口（返回值、參數表）被充分利用。函數在退出前應該設置這個全局變量的值為成功或者失敗（包括原因），而與返回值一樣，它隱含的要求調用者要在調用后檢查這個標志，這種約束實在是同樣軟弱。全局變量還導致了另外一個問題，就是多線程不安全：如果多個線程同時為一個全局變量賦值，則調用者在檢查這個標志的時候一定會非常迷惑。如果希望線程安全，可以參照errno的解決辦法，它是線程安全的。
setjmp()/longjmp()。可以認為它們是遠程的goto語句。根據我的經驗，它們好象確實不常被用到，也許是多少破壞了結構化編程風格的原因吧。在C++中，應該是更加的不要用它們，因為致命的弱點是longjmp()雖然會unwindingstack（這個詞后面再說），但是不會調用棧中對象的析構函數--夠致命吧。對於不同的編譯器，可能可以通過加某個編譯開關來解決這個問題，但太不通用了，會導致程序很難移植。
現在我們再來看看異常能解決什么問題。對於返回值和errno遇到的尷尬，對異常來說基本上不存在，如果你不捕獲(catch)程序中拋出的異常，默認行為是導致abort()被調用，程序被終止(coredump)。因此你的函數如果拋出了異常，這個函數的調用者或者調用者的調用者，也就是在當前的callstack上，一定要有一個地方捕獲這個異常。而對於setjmp()/longjmp()帶來的棧上對象不被析構的問題對異常來說也是不存在的。那么它是否破壞了結構化（對於OOparadigms，也許應該說是破壞了流程？）呢？顯然不是，有了異常之后你可以放心的只書寫正確的邏輯，而將所有的錯誤處理歸結到一個地方，這不是更好么？
綜上所述，在C++中大概異常可以全面替代其它的錯誤處理方式了，可是如果代碼中到處充斥着try/throw/catch也不是件好事，欲知異常的使用技巧，請保持耐心繼續閱讀:)
2.異常的語法
在這里我們只討論一些語法相關的問題。
try總是與catch一同出現，伴隨一個try語句，至少應該有一個catch()語句。try隨后的block是可能拋出異常的地方。
catch帶有一個參數，參數類型以及參數名字都由程序指定，名字可以忽略，如果在catch隨后的block中並不打算引用這個異常對象的話。參數類型可以是build-intype，例如int,long, char等，也可以是一個對象，一個對象指針或者引用。如果希望捕獲任意類型的異常，可以使用“...”作為catch的參數。
catch不一定要全部捕獲tryblock中拋出的異常，剩下沒有捕獲的可以交給上一級函數處理。
throw后面帶一個類型的實例，它和catch的關系就象是函數調用，catch指定形參，throw給出實參。編譯器按照catch出現的順序以及catch指定的參數類型確定一個異常應該由哪個catch來處理。
throw不一定非要出現在try隨后的block中，它可以出現在任何需要的地方，只要最終有catch可以捕獲它即可。即使在catch隨后的block中，仍然可以繼續throw。這時候有兩種情況，一是throw一個新類型的異常，這與普通的throw一樣。二是要rethrow當前這個異常，在這種情況下，throw不帶參數即可表達。例如：
try{
...
}
catch(int){
throwMyException("hello exception"); //拋出一個新的異常
}
catch(float){
throw; // 重新拋出當前的浮點數異常
}
還有一個地方與throw關鍵字有關，就是函數聲明。例如：
void foo() throw (int); //只能拋出int型異常
voidbar() throw (); //不拋出任何異常
voidbaz(); // 可以拋出任意類型的異常或者不拋出異常
如果一個函數的聲明中帶有throw限定符，則在函數體中也必須同樣出現：
void foo() throw (int)
{
...
}
這里有一個問題，非常隱蔽，就是即使你象上面一樣編寫了foo()函數，指定它只能拋出int異常，而實際上它還是可能拋出其他類型的異常而不被編譯器發現：
void foo() throw (int)
{
throw float; // 錯誤！異常類型錯誤！會被編譯器指出
...
baz(); // 正確！baz()可能拋出非int異常而編譯器又不能發現！
}
voidbaz()
{
throw float;
}
這種情況的直接后果就是如果baz()拋出了異常，而調用foo()的代碼又嚴格遵守foo()的聲明來編寫，那么程序將abort()。這曾經讓我很惱火，認為這種機制形同虛設，但是還是有些解決的辦法，請參照“使用技巧”中相關的問題。
3.異常使用技巧
3.1 異常是如何工作的
為了可以有把握的使用異常，我們先來看看異常處理是如何工作的。
我們知道，每次函數調用發生的時候，都會執行保護現場寄存器、參數壓棧、為被調用的函數創建堆棧這幾個對堆棧的操作，它們都使堆棧增長。每次函數返回則是恢復現場，使堆棧減小。我們把函數返回過程中恢復現場的過程稱為unwindingstack。
異常處理中的throw語句產生的效果與函數返回相同，它也引發unwindingstack。如果catch不是在throw的直接上層函數中，那么這個unwinding的過程會一直持續，直到找到合適的catch。如果沒有合適的catch，則最后std::unexpected()函數被調用，說明發現了一個沒想到的異常，這個函數會調用std::terminate()，這個terminate()調用abort()，程序終止(coredump)。
在“簡介”中提到的longjmp()也同樣會unwindingstack，但是這是一個C函數，它就象free()不會調用對象的析構函數一樣，它也不知道在unwindingstack的過程中調用棧上對象的析構函數。這是它與異常的主要區別。
在unwindingstack的過程中，程序會一直試圖找到一個“合適”的catch來處理這個異常。前面我們提到throw和catch的關系很象是函數調用和函數原型的關系，多個catch就好象一個函數被重載為可以接受不同的類型。根據這樣的猜測，好象找到合適的catch來處理異常與函數重載的過程中找到合適的函數原型是一樣的，沒有什么大不了的。但實際情況卻很困難，因為重載的調用在編譯時刻就可以確定，而異常的拋出卻不能，考慮下面的代碼：
void foo() throw (int)
{
throw int;
}
void bar()
{
try{
foo();
}
catch(int){
...
}
catch(float){
...
}
}
void baz()
{
try{
foo();
}
catch(int){
...
}
catch(float){
...
}
}
foo()在兩個地方被調用，這兩次異常被不同的catch捕獲，所以在為throw產生代碼的時候，無法明確的指出要由哪個catch捕獲，也就是說，無法在編譯時刻確定。
仍然考慮這個例子，讓我們來看看既然不能在編譯時刻確定throw的去向，那么在運行時刻如何確定。在bar()中，一列catch就象switch語句中的case一樣排列，實際上是一系列的判斷過程，依次檢查當前異常的類型是否滿足catch指定的類型，這種動態的，在運行時刻確定類型的技術就是RTTI(RuntimeTypeIdentification/Information)。深度探索C++對象模型[1]中提到，RTTI就是異常處理的副產品。關於RTTI又是一個話題，在這里就不詳細討論了。
是的。而且std::exception已經有了一些派生類，如果需要可以直接使用它們，不需要再重復定義了。
盡管前面已經分析了這樣做也有漏洞，但是它仍然是一個好習慣，可以讓調用者從頭文件得到非常明確的信息，而不用翻那些可能與代碼不同步的文檔。如果你提供一個庫，那么在庫的入口函數中應該使用catch(...)來捕獲所有異常，在catch(...)中捕獲的異常應該被轉換（rethrow）為throw列表中的某一個異常，這樣就可以保證不會產生意外的異常。
異常處理在unwindingstack的時候，會析構所有棧上的對象，但是卻不會自動刪除堆上的對象，甚至你的代碼中雖然寫了delete語句，但是卻被throw跳過，導致內存泄露，或者其它資源的泄露。例如：
void foo()
{
...
MyClass * p = new MyClass();
bar(p);
...
deletep; //如果bar()中拋出異常，則不會運行到這里！
}
voidbar(MyClass * p)
{
throw MyException();
}
對於這種情況，C++提供了std::auto_ptr這個模板來解決問題。這個常被稱為“智能指針”的模板原理就是，將原來代碼中的指針用一個棧上的模板實例保護起來，當發生異常unwindingstack的時候，這個模板實例會被析構，而在它的析構函數中，指針將被delete，例如：
void foo()
{
...
std::auto_ptr<MyClass> p(newMyClass());
bar(p.get());
...
// delete p; // 這句不再需要了
}
voidbar(MyClass * p)
{
throw MyException();
}
不論bar()是否拋出異常，只要p被析構，內存就會被釋放。
不光對於內存，對於其他資源的管理也可以參照這個方法來完成。在ACE[2]中，這種方式被稱為Guard，用來對鎖進行保護。
構造函數沒有返回值，很多地方都推薦通過拋出異常來通知調用者構造失敗。這是肯定是個好的辦法，但是也不很完美。主要是因為在構造函數中拋出異常並不會引發析構函數的調用，例如：
class foo
{
public:
~foo() {} // 這個函數將被調用
};
class bar
{
public:
bar() { c_ = new char[10]; throw -1;}
~bar() {delete c_;} // 這個函數不會被調用！
private:
char * c_;
foo f_;
};
void baz()
{
try{
bar b;
}
catch(int){
}
}
在這個例子中，bar的析構函數不會被調用，但是盡管如此，foo的析構函數還是可以被調用。危險的是在構造函數中分配空間的c_，因為析構函數沒有被調用而變成了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_;
};
析構函數中則不要拋出異常，這一點在ThinkingIn C++ Volume 2[3]中有明確表述。如果析構函數中調用了可能拋出異常的函數，則應該在析構函數內部catch它。
到現在為止，我們已經討論完了異常的大部分問題，可以實際操作操作了。實際應用中遇到的最讓我頭疼的問題就是什么時候應該使用異常，是否應該用異常全面代替“簡介”中提到的其它錯誤處理方式呢？
首先，不能用異常完全代替返回值，因為返回值的含義不一定只是成功或失敗，有時候是一個可選擇的狀態，例如：
if(customer->status() ==active){
...
}
else{
...
}
在這種情況下，不論返回值是什么，都是程序可以接受的正常的結果。而異常只能用來表達“異常”--也就是錯誤的狀態。這好象是顯而易見的事情，但是實際編程的過程中有很多更加模棱兩可的時候，遇到這樣的情況，首先要考慮的就是這個原則。
第二，看看在特定的情況下異常是否會發揮它的優點，而這個優點正好又不能使用其他技術達到（或者簡單的達到）。比如，如果你正在為電信公司寫一個復雜計費邏輯，那么你當然希望在整個計算費用的過程中集中精力去考慮業務邏輯方面的問題，而不是到處需要根據當前返回值判斷是否釋放前面步驟中申請的資源。這時候使用異常可以讓你的代碼非常清晰，即使你有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]中列了一個什么時候不應該用，什么時候應該用的表，大家可以參考一下。
最后，說一個與異常無關的東西，但也跟程序錯誤有關的，就是斷言(assert)，我在開發中使用了異常后，很快發現有的人將應該使用assert處理的錯誤定義成了異常。這里稍微提醒一下assert的用法，非常簡單的原則：只有對於那些可以通過改進程序糾正的錯誤，才可以用assert。返回值、異常顯然與其不在一個層面上，這是C的入門知識。
4 c++ 捕獲所有異常的寫法
try
{
device = createDevice(video::EDT_DIRECT3D9,
core::dimension2d<u32>(512, 384));
}
catch (...)
{
device = 0;
}
===2013.1.9 根據zhouaihui1010 的指出修改=========================
上面這種異常捕獲方式，對於c++ 除零錯誤， 內存錯誤等異常無法捕獲。
除零錯誤，可以用signal函數處理硬件中斷信號來處理。
try-catch異常捕獲的兩種模式有關。同步模式和異步模式。其中前者不能捕獲內存訪問錯誤，后者可以捕獲內存訪問錯誤。
/EHs是啟用同步模式。(同 /GX)
/EHa是起用異步模式。
VC的工程的調試版本缺省使用異步模式，工程的發布版本缺省使用同步模式。
實際上，win32開發中還有個Windows SEH 結構化異常。結構化異常是Windows操作系統提供的與語言無關的異常處理機制， SHE使用Win32API中的RaiseException()函數來拋出異常，在VC中使用關鍵字__try和關鍵字__except來捕獲，並用宏函數GetExceptionCode和GetExceptionInfo來獲取捕獲的異常由什么原因產生，和產生異常時環境狀態。__finally關鍵字保證無論是否發生異常，finally代碼段都會被執行。
---------------------------------------------------
由上種種可以看出，c++由於比較接近底層，因此程序員在擁有更大自由度的同時，也需要處理更多的問題。
異常的定義
如果一個位置所發生的事情最終能夠被正確的處理並使得程序如期正常運行，那么這件事情又怎么能被認為是一個錯誤呢？”事實上，我們把這類異常事件（或簡稱異常）以及用來處理這類事件的語言機制一起成為異常處理（exception handling）。
C++異常之我的見解
標准的c++庫里包含<exception><stdexcept>
其中<exception>之定義了最基本的exception類
<stdexcept>中定義了從exception類繼承出來的其他一般異常類
--------------------------------------------------------------------------------
exception 由C++標准庫為所有拋出異常的類提供的類庫.使用what()函數可以取得exception對象初始化時被設置的可選字符串.
logic_error 從exception類派生.報告程序邏輯錯誤,通過檢查代碼,能夠發現這類錯誤.
------------------------------------------------------------------------------
runtime_error 從exception類派生.報告運行時錯誤,只有在程序運行時,這類錯誤才可能被檢測到.
ios::failure 從exception類派生,沒有子類從logic_error派生的異常類:
domian_error 報告違反了前置條件
invalid_argument 表明拋出這個異常的函數接收到了一個無效的參數
length_error 表明程序試圖產生一個長度大於npos的對象
out_of_range 報告一個參數越界錯誤
-------------------------------------------------------------------------
bad_cast 拋出這個異常的原因是在運行時類型識別(runtimetype identification)中發現程序執行了 一個無效的動態類型轉換(dynamic_cast)表達式
------------------------------------------------------------------------------
bad_typeid 當表達式typeid(*p)中的參數p是一個空指針時拋出這個異常
--------------------------------------------------------------------------------從runtime_error派生的異常--------------------------------------------------------------------------------
range_error 報告違反了后置條件.
----------------------------------------------------------------------------
overflow_error 報告一個算術溢出錯誤
-----------------------------------------------------------------------------
bad_alloc 報告一個失敗的存儲分配
本質
異常類雖然多但是,只是定義一種規范而已,類本身沒有和類名相對應任何處理語句,他就像書的目錄一樣,只是起到一種歸類的作用本身沒有任何內容.
真正實現的異常的地方是在一個獨立的框架或平台中通過判斷不同的條件throw出來的,throw的信息可以穿越多層函數最后返回到catch的地方.
但是有一點需要主意有時在面向過程的編程(如c++的c編程風格)中他會打亂程序的順序,有可能是某些狀態無效,所以在處理完異常后需要重新設置狀態.
還有一點就是通過沒有經過驗證需進一步來驗證
A--B(B繼承自A)
Throw了B類的異常
再catchA類異常的時候可以捕獲B類的異常
所以在CATCH的時候要把子類放在前面?????
作者：張笑猛
原文出處：http://objects.nease.net/