C++異常處理：try,catch,throw,finally的用法

寫在前面

所謂異常處理，即讓一個程式執行時遇到自己無法處理的錯誤時丟擲一個異常，希望呼叫者可以發現處理問題.

異常處理的基本思想是簡化程式的錯誤程式碼，為程式鍵壯性提供一個標準檢測機制.

也許我們已經使用過異常，但是你習慣使用異常了嗎？

現在很多軟體都是n*365*24小時執行，軟體的健壯性至關重要.

內容導讀

本文包括2個大的異常實現概念：C++的標準異常和SEH異常.

C++標準異常：

也許你很高興看到錯誤之後的Heap/Stack中物件被釋放，可是如果沒有呢？

又或者試想一下一個能解決的錯誤，需要我們把整個程式Kill掉嗎？

在《C++標準異常》中我向你推薦這幾章：

<使用異常規格程式設計> <構造和析構中的異常丟擲> <使用解構函式防止資源洩漏>,以及深入一點的<丟擲一個異常的行為>.

SEH異常：

我要問你你是一個WIN32程式設計師嗎？如果不是，那麼也許你真的不需要看.

SEH是Windows的結構化異常，每一個WIN32程式設計師都應該要掌握它.

SEH功能強大，包括Termination handling和Exception handling兩大部分.

強有力的維護了程式碼的健壯，雖然要以部分系統效能做犧牲(其實可以避免).

在SEH中有大量的程式碼，已經在Win平臺上測試過了.

這裡要提一下：在__finally處理中編譯器參與了絕大多數的工作，而Exception則是OS接管了幾乎所有的工作，也許我沒有提到的是：

對__finally來說當遇到ExitThread/ExitProcess/abort等函式時，finally塊不會被執行.

另:<使用解構函式防止資源洩漏>這個節點引用了More effective C++的條款9.

用2個列子，講述了我們一般都會犯下的錯誤，往往這種錯誤是我們沒有意識到的但確實是會給我們的軟體帶來致命的Leak/Crash，但這是有解決的方法的，那就是使用“靈巧指標”.

如果對照<More effective C++>的37條條款，關於異常的高階使用，有以下內容是沒有完成的：

• 使用建構函式防止資源Leak（More effective C++ #10）
• 禁止異常資訊傳遞到析構Function外 (More effective C++ #11)
• 通過引用捕獲異常 （More effective C++ #13）
• 謹慎使用異常規格  （More effective C++ #14）
• 瞭解異常處理造成的系統開銷 （More effective C++ #15）
• 限制物件數量 （More effective C++ #26）
• 靈巧指標 （More effective C++ #28）

C++異常

C++引入異常的原因:

例如使用未經處理的pointer變的很危險，Memory/Resource Leak變的更有可能了.

寫出一個具有你希望的行為的建構函式和解構函式也變的困難（不可預測），當然最危險的也許是我們寫出的東東狗屁了，或者是速度變慢了.

大多數的程式設計師知道Howto use exception 來處理我們的程式碼，可是很多人並不是很重視異常的處理（國外的很多Code倒是處理的很好，Java的Exception機制很不錯）.

異常處理機制是解決某些問題的上佳辦法，但同時它也引入了許多隱藏的控制流程；有時候，要正確無誤的使用它並不容易.

在異常被throw後，沒有一個方法能夠做到使軟體的行為具有可預測性和可靠性

對C程式來說，使用Error Code就可以了，為什麼還要引入異常？因為異常不能被忽略.

如果一個函式通過設定一個狀態變數或返回錯誤程式碼來表示一個異常狀態，沒有辦法保證函式呼叫者將一定檢測變數或測試錯誤程式碼.

結果程式會從它遇到的異常狀態繼續執行，異常沒有被捕獲，程式立即會終止執行.

在C程式中，我們可以用int setjmp( jmp_buf env );和 void longjmp( jmp_buf env, int value );

這2個函式來完成和異常處理相識的功能，但是MSDN中介紹了在C++中使用longjmp來調整stack時不能夠對區域性的物件呼叫解構函式，

但是對C++程式來說，解構函式是重要的（我就一般都把物件的Delete放在解構函式中）.

所以我們需要一個方法：

• 能夠通知異常狀態，又不能忽略這個通知.
• 並且Searching the stack以便找到異常程式碼時.
• 還要確保區域性物件的解構函式被Call.

而C++的異常處理剛好就是來解決這些問題的.

有的地方只有用異常才能解決問題，比如說，在當前上下文環境中，無法捕捉或確定的錯誤型別，我們就得用一個異常丟擲到更大的上下文環境當中去.

還有，異常處理的使用呢，可以使出錯處理程式與“通常”程式碼分離開來，使程式碼更簡潔更靈活.

另外就是程式必不可少的健壯性了，異常處理往往在其中扮演著重要的角色.

C++使用throw關鍵字來產生異常，try關鍵字用來檢測的程式塊，catch關鍵字用來填寫異常處理的程式碼.

異常可以由一個確定類或派生類的物件產生。C++能釋放堆疊，並可清除堆疊中所有的物件.

C++的異常和pascal不同，是要程式設計師自己去實現的，編譯器不會做過多的動作.

throw異常類程式設計,丟擲異常用throw， 如：

throw ExceptionClass(“my throw“);

例句中，ExceptionClass是一個類，它的建構函式以一個字串做為引數.

也就是說，在throw的時候，C++的編譯器先構造一個ExceptionClass的物件，讓它作為throw的值丟擲去,同時，程式返回，呼叫析構.

看下面這個程式：

#include <iostream.h>
class ExceptionClass
{
     char* name;
public:
     ExceptionClass(const char* name="default name")
     {
           cout<<"Construct "<<name<<endl;
           this->name=name;
     }
     ~ExceptionClass()
     {
           cout<<"Destruct "<<name<<endl;
     }
     void mythrow()
     {
           throw ExceptionClass("my throw");
     }
}

void main()
{
     ExceptionClass e("Test");
     try
     {
           e.mythrow();
     }
     catch(...)
     {
           cout<<”*********”<<endl;
     }
}

這是輸出資訊：

Construct Test
Construct my throw
Destruct my throw
****************
Destruct my throw   （這裡是異常處理空間中對異常類的拷貝的析構）
Destruct Test
======================================

不過一般來說我們可能更習慣於把會產生異常的語句和要throw的異常類分成不同的類來寫，下面的程式碼可以是我們更願意書寫的.

class ExceptionClass
{
public:
     　　ExceptionClass(const char* name="Exception Default Class")
     {
           　　cout<<"Exception Class Construct String"<<endl;
     }
     　　 ~ExceptionClass()
     {
           　　  cout<<"Exception Class Destruct String"<<endl;
     }
     　　 void ReportError()
     {
           　　  cout<<"Exception Class:: This is Report Error Message"<<endl;
     }
};

class ArguClass
{
     　　 char* name;
public:
     　　 ArguClass(char* name="default name")
     {
           　　  cout<<"Construct String::"<<name<<endl;
           　　  this->name=name;
     }
     ~ArguClass()
     {
           　　  cout<<"Destruct String::"<<name<<endl;
     }
     void mythrow()
     {
           　　  throw ExceptionClass("my throw");
     }
};

_tmain()
{
     ArguClass e("haha");
     　　 try
     {
           　　　　  e.mythrow();
     }
     catch(int)
     {
           　　  cout<<"If This is Message display screen, This is a Error!!"<<endl;
     }
     catch(ExceptionClass pTest)
     {
           　　  pTest.ReportError();
     }
     catch(...)
     {
           　　  cout<<"***************"<<endl;
     }
}

輸出Message：

Construct String::haha
Exception Class Construct String
Exception Class Destruct String
Exception Class:: This is Report Error Message
Exception Class Destruct String
Destruct String::haha

使用異常規格程式設計

如果我們呼叫別人的函式，裡面有異常丟擲，用去檢視它的原始碼去看看都有什麼異常丟擲嗎？這樣就會很煩瑣.

比較好的解決辦法，是編寫帶有異常丟擲的函式時，採用異常規格說明，使我們看到函式宣告就知道有哪些異常出現。

異常規格說明大體上為以下格式：

void ExceptionFunction(argument…)
throw(ExceptionClass1, ExceptionClass2, ….)

所有異常類都在函式末尾的throw()的括號中得以說明了，這樣，對於函式呼叫者來說，是一清二楚的。

注意下面一種形式：

void ExceptionFunction(argument…) throw()

表明沒有任何異常丟擲.

而正常的void ExceptionFunction(argument…)則表示：可能丟擲任何一種異常，當然，也可能沒有異常，意義是最廣泛的.

異常捕獲之後，可以再次丟擲，就用一個不帶任何引數的throw語句就可以了.

構造和析構中的異常丟擲

這是異常處理中最要注意的地方了

先看個程式，假如我在建構函式的地方丟擲異常，這個類的析構會被呼叫嗎？可如果不呼叫，那類裡的東西豈不是不能被釋放了？

#include <iostream.h>
#include <stdlib.h>

class ExceptionClass1
{
     char* s;
public:
     ExceptionClass1()
     {
           cout<<"ExceptionClass1()"<<endl;
           s=new char[4];
           cout<<"throw a exception"<<endl;
           throw 18;
     }
     ~ExceptionClass1()
     {
           cout<<"~ExceptionClass1()"<<endl;
           delete[] s;
     }
};

void main()
{
     try
     {
           ExceptionClass1 e;
     }
     catch(...)
     {}
}

結果為：

ExceptionClass1()
throw a exception

在這兩句輸出之間，我們已經給S分配了記憶體，但記憶體沒有被釋放（因為它是在解構函式中釋放的）.

應該說這符合實際現象，因為物件沒有完整構造.

為了避免這種情況，我想你也許會說：應避免物件通過本身的建構函式涉及到異常丟擲.

即：既不在建構函式中出現異常丟擲，也不應在建構函式呼叫的一切東西中出現異常丟擲.

但是在C++中可以在建構函式中丟擲異常，經典的解決方案是使用STL的標準類auto_ptr.

其實我們也可以這樣做來實現：

在類中增加一個 Init()以及 UnInit();成員函式用於進行容易產生錯誤的資源分配工作，而真正的建構函式中先將所有成員置為NULL，然後呼叫 Init();

並判斷其返回值/或者捕捉 Init()丟擲的異常，如果Init();失敗了，則在建構函式中呼叫 UnInit(); 並設定一個標誌位表明構造失敗.

UnInit()中按照成員是否為NULL進行資源的釋放工作.

那麼，在解構函式中的情況呢？

我們已經知道，異常丟擲之後，就要呼叫本身的解構函式，如果這解構函式中還有異常丟擲的話，則已存在的異常尚未被捕獲，會導致異常捕捉不到.

標準C++異常類

C++有自己的標準的異常類.

一個基類

exception 是所有C++異常的基類.

class exception {
public:
   exception() throw();
   exception(const exception& rhs) throw();
   exception& operator=(const exception& rhs) throw();
   virtual ~exception() throw();
   virtual const char *what() const throw();
};

派生了兩個異常類

• logic_erro       報告程式的邏輯錯誤，可在程式執行前被檢測到.
• runtime_erro     報告程式執行時的錯誤，只有在執行的時候才能檢測到.

以上兩個又分別有自己的派生類：

• 由logic_erro派生的異常類

  domain_error           報告違反了前置條件
  invalid_argument       指出函式的一個無效引數
  length_error 　　　　　　指出有一個產生超過NPOS長度的物件的企圖（NPOS為size_t的最大可表現值
  out_of_range 　　　　　　報告引數越界
  bad_cast               在執行時型別識別中有一個無效的dynamic_cast表示式
  bad_typeid 　　　　　　　報告在表示式typeid(*p)中有一個空指標P

• 由runtime_error派生的異常

  range_error　　　　 報告違反了後置條件
  overflow_error 　　報告一個算術溢位
  bad_alloc          報告一個儲存分配錯誤

使用解構函式防止資源洩漏

這部分是一個經典和很平常就會遇到的實際情況，下面的內容大部分都是從More Effective C++條款中得到的.

假設，你正在為一個小動物收容所編寫軟體，小動物收容所是一個幫助小狗小貓尋找主人的組織.

每天收容所建立一個檔案，包含當天它所管理的收容動物的資料資訊，你的工作是寫一個程式讀出這些檔案然後對每個收容動物進行適當的處理（appropriate processing）.

完成這個程式一個合理的方法是定義一個抽象類，ALA（”Adorable Little Animal”)，然後為小狗和小貓建立派生類.

一個虛擬函式processAdoption分別對各個種類的動物進行處理：

class ALA {
public:
　virtual void processAdoption() = 0;
　...
};
class Puppy: public ALA {
public:
　virtual void processAdoption();
　...
};
class Kitten: public ALA {
public:
　virtual void processAdoption();
　...
};

你需要一個函式從檔案中讀資訊，然後根據檔案中的資訊產生一個puppy（小狗）物件或者kitten(小貓)物件.

這個工作非常適合於虛擬構造器（virtual constructor），在條款25詳細描述了這種函式.

為了完成我們的目標，我們這樣宣告函式：

// 從s中讀動物資訊, 然後返回一個指標
// 指向新建立的某種型別物件
ALA * readALA(istream& s);

你的程式的關鍵部分就是這個函式，如下所示：

void processAdoptions(istream& dataSource)
{
     while(dataSource)
     {
           ALA *pa = readALA(dataSource); //得到下一個動物
           pa->processAdoption(); //處理收容動物
           delete pa; //刪除readALA返回的物件
     }　　　　　　　　　　　　　　　　　
}

這個函式迴圈遍歷dataSource內的資訊，處理它所遇到的每個專案.

唯一要記住的一點是在每次迴圈結尾處刪除ps.

這是必須的，因為每次呼叫readALA都建立一個堆物件.如果不刪除物件，迴圈將產生資源洩漏。

現在考慮一下，如果pa->processAdoption丟擲了一個異常，將會發生什麼？

processAdoptions沒有捕獲異常，所以異常將傳遞給processAdoptions的呼叫者.

轉遞中，processAdoptions函式中的呼叫pa->processAdoption語句後的所有語句都被跳過，這就是說pa沒有被刪除.

結果，任何時候pa->processAdoption丟擲一個異常都會導致processAdoptions記憶體洩漏，很容易堵塞洩漏.

void processAdoptions(istream& dataSource)
{
     while(dataSource)
     {
           ALA *pa = readALA(dataSource);
           try
           {
                 pa->processAdoption();
           }
           catch(...)
           {
                 　　　　　　　// 捕獲所有異常
                 delete pa; 　　　　　　　 // 避免記憶體洩漏
                 　　　　　　　　　　　　　　 // 當異常丟擲時
                 throw; 　　　　　　　　　 // 傳送異常給呼叫者
           }
           delete pa; 　　　　　　　　 // 避免資源洩漏
     }　　　　　　　　　　　　　 // 當沒有異常丟擲時
}

但是你必須用try和catch對你的程式碼進行小改動.

更重要的是你必須寫雙份清除程式碼，一個為正常的執行準備，一個為異常發生時準備.

在這種情況下，必須寫兩個delete程式碼.

象其它重複程式碼一樣，這種程式碼寫起來令人心煩又難於維護，而且它看上去好像存在著問題.

不論我們是讓processAdoptions正常返回還是丟擲異常，我們都需要刪除pa，所以為什麼我們必須要在多個地方編寫刪除程式碼呢？

我們可以把總被執行的清除程式碼放入processAdoptions函式內的區域性物件的解構函式裡，這樣可以避免重複書寫清除程式碼.

因為當函式返回時區域性物件總是被釋放，無論函式是如何退出的.

（僅有一種例外就是當你呼叫longjmp時。Longjmp的這個缺點是C++率先支援異常處理的主要原因）

具體方法是用一個物件代替指標pa，這個物件的行為與指標相似。當pointer-like（類指標）物件被釋放時，我們能讓它的解構函式呼叫delete.

替代指標的物件被稱為smart pointers（靈巧指標），下面有解釋，你能使得pointer-like物件非常靈巧.

在這裡，我們用不著這麼聰明的指標，我們只需要一個pointer-lik物件，當它離開生存空間時知道刪除它指向的物件.

寫出這樣一個類並不困難，但是我們不需要自己去寫。標準C++庫函式包含一個類别範本，叫做auto_ptr，這正是我們想要的.

每一個auto_ptr類的建構函式裡，讓一個指標指向一個堆物件（heap object），並且在它的解構函式裡刪除這個物件.

下面所示的是auto_ptr類的一些重要的部分：

template<class T>
class auto_ptr
{
public:
     　auto_ptr(T *p = 0): ptr(p) {}　　　　// 儲存ptr，指向物件
     　~auto_ptr() { delete ptr; }　　　　　// 刪除ptr指向的物件
private:
     　T *ptr;          　 // raw ptr to object
};

auto_ptr類的完整程式碼是非常有趣的，上述簡化的程式碼實現不能在實際中應用.

（我們至少必須加上拷貝建構函式，賦值operator以及下面將要講到的pointer-emulating函式）

但是它背後所蘊含的原理應該是清楚的：用auto_ptr物件代替raw指標，你將不再為堆物件不能被刪除而擔心，即使在丟擲異常時，物件也能被及時刪除.

(因為auto_ptr的解構函式使用的是單物件形式的delete，所以auto_ptr不能用於指向物件陣列的指標.

如果想讓auto_ptr類似於一個陣列模板，你必須自己寫一個。在這種情況下，用vector代替array可能更好)

auto_ptr
template<class T>
class auto_ptr
{
public:
     typedef T element_type;
     explicit auto_ptr(T *p = 0) throw();
     auto_ptr(const auto_ptr<T>& rhs) throw();
     auto_ptr<T>& operator=(auto_ptr<T>& rhs) throw();
     ~auto_ptr();
     T& operator*() const throw();
     T *operator->() const throw();
     T *get() const throw();
     T *release() const throw();
};

使用auto_ptr物件代替raw指標，processAdoptions如下所示：

void processAdoptions(istream& dataSource)
{
     while(dataSource)
     {
           auto_ptr<ALA> pa(readALA(dataSource));
           pa->processAdoption();
     }
}

這個版本的processAdoptions在兩個方面區別於原來的processAdoptions函式：

• pa被宣告為一個auto_ptr<ALA>物件，而不是一個raw ALA*指標.
• 在迴圈的結尾沒有delete語句.

其餘部分都一樣，因為除了析構的方式，auto_ptr物件的行為就象一個普通的指標。是不是很容易.

隱藏在auto_ptr後的思想是：

用一個物件儲存需要被自動釋放的資源，然後依靠物件的解構函式來釋放資源，這種思想不只是可以運用在指標上，還能用在其它資源的分配和釋放上.

想一下這樣一個在GUI程式中的函式，它需要建立一個window來顯式一些資訊：

// 這個函式會發生資源洩漏，如果一個異常丟擲
void displayInfo(const Information& info)
{
     　WINDOW_HANDLE w(createWindow());//在w對應的window中顯式資訊
     　destroyWindow(w);
}

很多window系統有C－like介面，使用象like createWindow 和 destroyWindow函式來獲取和釋放window資源.

如果在w對應的window中顯示資訊時，一個異常被丟擲，w所對應的window將被丟失，就象其它動態分配的資源一樣.

解決方法與前面所述的一樣，建立一個類，讓它的建構函式與解構函式來獲取和釋放資源：

//一個類，獲取和釋放一個window 控制程式碼
class WindowHandle
{
public:
     　 WindowHandle(WINDOW_HANDLE handle): w(handle) {}
     　~WindowHandle() { destroyWindow(w); }
     　 operator WINDOW_HANDLE() { return w; }　　　　// see below
private:
     　WINDOW_HANDLE w;
     　// 下面的函式被宣告為私有，防止建立多個WINDOW_HANDLE拷貝
     //有關一個更靈活的方法的討論請參見下面的靈巧指標
     　WindowHandle(const WindowHandle&);
     　WindowHandle& operator=(const WindowHandle&);
};

這看上去有些象auto_ptr，只是賦值操作與拷貝構造被顯式地禁止（參見More effective C++條款27），有一個隱含的轉換操作能把WindowHandle轉換為WINDOW_HANDLE.

這個能力對於使用WindowHandle物件非常重要，因為這意味著你能在任何地方象使用raw WINDOW_HANDLE一樣來使用WindowHandle.

（參見More effective C++條款5 ，瞭解為什麼你應該謹慎使用隱式型別轉換操作）

通過給出的WindowHandle類，我們能夠重寫displayInfo函式，如下所示：

// 如果一個異常被丟擲，這個函式能避免資源洩漏
void displayInfo(const Information& info)
{
     WindowHandle w(createWindow());
     //在w對應的window中顯式資訊;
}

即使一個異常在displayInfo內被丟擲，被createWindow 建立的window也能被釋放.

資源應該被封裝在一個物件裡，遵循這個規則，你通常就能避免在存在異常環境裡發生資源洩漏.

但是如果你正在分配資源時一個異常被丟擲，會發生什麼情況呢？

例如當你正處於resource-acquiring類的建構函式中.

還有如果這樣的資源正在被釋放時，一個異常被丟擲，又會發生什麼情況呢？

建構函式和解構函式需要特殊的技術.

你能在More effective C++條款10和More effective C++條款11中獲取有關的知識.

丟擲一個異常的行為

個人認為接下來的這部分其實說的很經典，對我們理解異常行為/異常拷貝是很有幫助的.

條款12：理解“丟擲一個異常”與“傳遞一個引數”或“呼叫一個虛擬函式”間的差異

從語法上看，在函式裡宣告引數與在catch子句中宣告引數幾乎沒有什麼差別：

class Widget { ... };                 //一個類，具體是什麼類在這裡並不重要
void f1(Widget w);                    // 一些函式，其引數分別為
void f2(Widget& w);                   // Widget, Widget&,或
void f3(const Widget& w);             // Widget* 型別
void f4(Widget *pw);
void f5(const Widget *pw);
catch(Widget w) ...                  //一些catch 子句，用來
catch(Widget& w)   ...               //捕獲異常，異常的型別為
catch(const Widget& w) ...            // Widget, Widget&, 或
catch(Widget *pw) ...                 // Widget*
catch(const Widget *pw) ...

你因此可能會認為用throw丟擲一個異常到catch子句中與通過函式呼叫傳遞一個引數兩者基本相同.

這裡面確有一些相同點，但是他們也存在著巨大的差異.

讓我們先從相同點談起.

你傳遞函式引數與異常的途徑可以是傳值、傳遞引用或傳遞指標，這是相同的.

但是當你傳遞引數和異常時，系統所要完成的操作過程則是完全不同的.

產生這個差異的原因是：你呼叫函式時，程式的控制權最終還會返回到函式的呼叫處，但是當你丟擲一個異常時，控制權永遠不會回到丟擲異常的地方。

有這樣一個函式，引數型別是Widget，並丟擲一個Widget型別的異常：

// 一個函式，從流中讀值到Widget中
istream operator>>(istream& s, Widget& w);
void passAndThrowWidget()
{
     Widget localWidget;
     cin >> localWidget;          //傳遞localWidget到 operator>>
     throw localWidget;           // 丟擲localWidget異常
}

當傳遞localWidget到函式operator>>裡，不用進行拷貝操作，而是把operator>>內的引用型別變數w指向localWidget，任何對w的操作實際上都施加到localWidget上.

這與丟擲localWidget異常有很大不同.

不論通過傳值捕獲異常還是通過引用捕獲（不能通過指標捕獲這個異常，因為型別不匹配）都將進行lcalWidget的拷貝操作，也就說傳遞到catch子句中的是localWidget的拷貝.

必須這麼做，因為當localWidget離開了生存空間後，其解構函式將被呼叫.

如果把localWidget本身（而不是它的拷貝）傳遞給catch子句，這個子句接收到的只是一個被析構了的Widget，一個Widget的“屍體”.

這是無法使用的。因此C++規範要求被做為異常丟擲的物件必須被複制.

即使被丟擲的物件不會被釋放，也會進行拷貝操作.

例如如果passAndThrowWidget函式宣告localWidget為靜態變數（static）：

void passAndThrowWidget()
{
     static Widget localWidget;        // 現在是靜態變數（static） 一直存在至程式結束
     cin >> localWidget;               // 象以前那樣執行
     throw localWidget;                // 仍將對localWidget進行拷貝操作
}

當丟擲異常時仍將複製出localWidget的一個拷貝.

這表示即使通過引用來捕獲異常，也不能在catch塊中修改localWidget;僅僅能修改localWidget的拷貝.

對異常物件進行強制複製拷貝，這個限制有助於我們理解引數傳遞與丟擲異常的第二個差異：丟擲異常執行速度比引數傳遞要慢.

當異常物件被拷貝時，拷貝操作是由物件的拷貝建構函式完成的.

該拷貝建構函式是物件的靜態型別（static type）所對應類的拷貝建構函式，而不是物件的動態型別（dynamic type）對應類的拷貝建構函式.

比如以下這經過少許修改的passAndThrowWidget:

class Widget { ... };
class SpecialWidget: public Widget { ... };
void passAndThrowWidget()
{
     SpecialWidget localSpecialWidget;
     ...
     Widget& rw = localSpecialWidget;      // rw 引用SpecialWidget
     throw rw;                             //它丟擲一個型別為Widget的異常
}

這裡丟擲的異常物件是Widget，即使rw引用的是一個SpecialWidget.

因為rw的靜態型別（static type）是Widget，而不是SpecialWidget.

你的編譯器根本沒有主要到rw引用的是一個SpecialWidget。編譯器所注意的是rw的靜態型別（static type）.

這種行為可能與你所期待的不一樣，但是這與在其他情況下C++中拷貝建構函式的行為是一致的.

（不過有一種技術可以讓你根據物件的動態型別dynamic type進行拷貝，參見條款25）

異常是其它物件的拷貝，這個事實影響到你如何在catch塊中再丟擲一個異常.

比如下面這兩個catch塊，乍一看好像一樣：

catch(Widget& w)                  // 捕獲Widget異常
{
     ...                             // 處理異常
     throw;                          // 重新丟擲異常，讓它
}                                 // 繼續傳遞
catch(Widget& w)                  // 捕獲Widget異常
{
     ...                             // 處理異常
     throw w;                        // 傳遞被捕獲異常的
}                                 // 拷貝

這兩個catch塊的差別在於第一個catch塊中重新丟擲的是當前捕獲的異常，而第二個catch塊中重新丟擲的是當前捕獲異常的一個新的拷貝.

如果忽略生成額外拷貝的系統開銷，這兩種方法還有差異麼？
當然有。第一個塊中重新丟擲的是當前異常（current exception）,無論它是什麼型別.

特別是如果這個異常開始就是做為SpecialWidget型別丟擲的，那麼第一個塊中傳遞出去的還是SpecialWidget異常，即使w的靜態型別（static type）是Widget.

這是因為重新丟擲異常時沒有進行拷貝操作.

第二個catch塊重新丟擲的是新異常，型別總是Widget，因為w的靜態型別（static type）是Widget.

一般來說，你應該用throw來重新丟擲當前的異常，因為這樣不會改變被傳遞出去的異常型別，而且更有效率，因為不用生成一個新拷貝.

（順便說一句，異常生成的拷貝是一個臨時物件.

正如條款19解釋的，臨時物件能讓編譯器優化它的生存期（optimize it out of existence），

不過我想你的編譯器很難這麼做，因為程式中很少發生異常，所以編譯器廠商不會在這方面花大量的精力）

讓我們測試一下下面這三種用來捕獲Widget異常的catch子句，異常是做為passAndThrowWidgetp丟擲的：

catch (Widget w) ...                // 通過傳值捕獲異常
catch (Widget& w) ...               // 通過傳遞引用捕獲異常
catch (const Widget& w) ...         //通過傳遞指向const的引用捕獲異常

我們立刻注意到了傳遞引數與傳遞異常的另一個差異.

一個被異常丟擲的物件（剛才解釋過，總是一個臨時物件）可以通過普通的引用捕獲.

它不需要通過指向const物件的引用（reference-to-const）捕獲.

在函式呼叫中不允許轉遞一個臨時物件到一個非const引用型別的引數裡（參見條款19），但是在異常中卻被允許.

讓我們先不管這個差異，回到異常物件拷貝的測試上來.

我們知道當用傳值的方式傳遞函式的引數，我們製造了被傳遞物件的一個拷貝（參見Effective C++ 條款22），並把這個拷貝儲存到函式的引數裡.

同樣我們通過傳值的方式傳遞一個異常時，也是這麼做的。當我們這樣宣告一個catch子句時:

catch (Widget w) ...                // 通過傳值捕獲

會建立兩個被丟擲物件的拷貝，一個是所有異常都必須建立的臨時物件，第二個是把臨時物件拷貝進w中.

同樣，當我們通過引用捕獲異常時:

catch (Widget& w) ...               // 通過引用捕獲
catch (const Widget& w) ...         file://也通過引用捕獲

這仍舊會建立一個被丟擲物件的拷貝：拷貝是一個臨時物件.

相反當我們通過引用傳遞函式引數時，沒有進行物件拷貝.

當丟擲一個異常時，系統構造的（以後會析構掉）被丟擲物件的拷貝數比以相同物件做為引數傳遞給函式時構造的拷貝數要多一個.

我們還沒有討論通過指標丟擲異常的情況，不過通過指標丟擲異常與通過指標傳遞引數是相同的.

不論哪種方法都是一個指標的拷貝被傳遞.

你不能認為丟擲的指標是一個指向區域性物件的指標，因為當異常離開區域性變數的生存空間時，該區域性變數已經被釋放.

Catch子句將獲得一個指向已經不存在的物件的指標。這種行為在設計時應該予以避免.

物件從函式的呼叫處傳遞到函式引數裡與從異常丟擲點傳遞到catch子句裡所採用的方法不同，

這只是引數傳遞與異常傳遞的區別的一個方面，第二個差異是在函式呼叫者或丟擲異常者與被呼叫者或異常捕獲者之間的型別匹配的過程不同.

比如在標準數學庫（the standard math library）中sqrt函式：

double sqrt(double);      // from <cmath> or <math.h>

我們能這樣計算一個整數的平方根，如下所示：

int i;
double sqrtOfi = sqrt(i);

毫無疑問，C++允許進行從int到double的隱式型別轉換，所以在sqrt的呼叫中，i 被悄悄地轉變為double型別，並且其返回值也是double.

（有關隱式型別轉換的詳細討論參見條款5）一般來說，catch子句匹配異常型別時不會進行這樣的轉換.

見下面的程式碼：

void f(int value)
{
     try
     {
           if(someFunction())         // 如果 someFunction()返回
           {
                 throw value;             //真，丟擲一個整形值
                 ...
           }
     }
     catch(double d)              // 只處理double型別的異常
     {
           ...
     }
     ...
}

在try塊中丟擲的int異常不會被處理double異常的catch子句捕獲.

該子句只能捕獲真真正正為double型別的異常；不進行型別轉換.

因此如果要想捕獲int異常，必須使用帶有int或int&引數的catch子句.

不過在catch子句中進行異常匹配時可以進行兩種型別轉換.

第一種是繼承類與基類間的轉換.

一個用來捕獲基類的catch子句也可以處理派生類型別的異常.

例如在標準C++庫（STL）定義的異常類層次中的診斷部分（diagnostics portion ）(參見Effective C++ 條款49).

捕獲runtime_errors異常的Catch子句可以捕獲range_error型別和overflow_error型別的異常，

可以接收根類exception異常的catch子句能捕獲其任意派生類異常.

這種派生類與基類（inheritance_based）間的異常型別轉換可以作用於數值、引用以及指標上：

catch (runtime_error) ...               // can catch errors of type
catch (runtime_error&) ...              // runtime_error,
catch (const runtime_error&) ...        // range_error, or overflow_error
catch (runtime_error*) ...              // can catch errors of type
catch (const runtime_error*) ...        // runtime_error*,range_error*, oroverflow_error*

第二種是允許從一個型別化指標（typed pointer）轉變成無型別指標（untyped pointer），

所以帶有const void* 指標的catch子句能捕獲任何型別的指標型別異常：

catch (const void*) …                 file://捕獲任何指標型別異常

傳遞引數和傳遞異常間最後一點差別是catch子句匹配順序總是取決於它們在程式中出現的順序.

因此一個派生類異常可能被處理其基類異常的catch子句捕獲，即使同時存在有能處理該派生類異常的catch子句，與相同的try塊相對應.

例如：

try
{
     ...
}
catch(logic_error& ex)                 // 這個catch塊 將捕獲
{
     ...                                  // 所有的logic_error
}                                      // 異常, 包括它的派生類
catch(invalid_argument& ex)            // 這個塊永遠不會被執行
{
     ...                                    //因為所有的invalid_argument異常 都被上面的catch子句捕獲
}

與上面這種行為相反，當你呼叫一個虛擬函式時，被呼叫的函式位於與發出函式呼叫的物件的動態型別（dynamic type）最相近的類裡.

你可以這樣說虛擬函式採用最優適合法，而異常處理採用的是最先適合法.

如果一個處理派生類異常的catch子句位於處理基類異常的catch子句前面，編譯器會發出警告.

（因為這樣的程式碼在C++裡通常是不合法的）

不過你最好做好預先防範：不要把處理基類異常的catch子句放在處理派生類異常的catch子句的前面.

上面那個例子，應該這樣去寫：

try
{
     ...
}
catch(invalid_argument& ex)             // 處理 invalid_argument
{
     ...
}
catch(logic_error& ex)                  // 處理所有其它的
{
     ...                                   // logic_errors異常
}

綜上所述，把一個物件傳遞給函式或一個物件呼叫虛擬函式與把一個物件做為異常丟擲，這之間有三個主要區別.

第一、異常物件在傳遞時總被進行拷貝；當通過傳值方式捕獲時，異常物件被拷貝了兩次.

物件做為引數傳遞給函式時不需要被拷貝.

第二、物件做為異常被丟擲與做為引數傳遞給函式相比，前者型別轉換比後者要少（前者只有兩種轉換形式）.

最後一點，catch子句進行異常型別匹配的順序是它們在原始碼中出現的順序，第一個型別匹配成功的catch將被用來執行.

當一個物件呼叫一個虛擬函式時，被選擇的函式位於與物件型別匹配最佳的類裡，即使該類不是在原始碼的最前頭.

靈巧指標

第一次用到靈巧指標是在寫ADO程式碼的時候，用到com_ptr_t靈巧指標；但一直印象不是很深；

其實靈巧指標的作用很大，對我們來說垃圾回收，ATL等都會使用到它.

在More effective 的條款後面特意增加這個節點，不僅是想介紹它在異常處理方面的作用，還希望對編寫別的型別程式碼的時候可以有所幫助.

smart pointer（靈巧指標）其實並不是一個指標,其實是某種形式的類.

不過它的特長就是模仿C/C++中的指標，所以就叫pointer 了.

所以希望大家一定要記住兩點：smart pointer是一個類而非指標，但特長是模仿指標.

那怎麼做到像指標的呢？

C++的模板技術和運算子過載給了很大的發揮空間.

首先smart pointer必須是高度型別化的（strongly typed ），模板給了這個功能.

其次需要模仿指標主要的兩個運算子->和*，那就需要進行運算子過載.

詳細的實現：

template<CLASS&NBSP; T> class SmartPtr
{
public:
     　　SmartPtr(T* p = 0);
     　　SmartPtr(const SmartPtr& p);
     　　~SmartPtr();
     　　SmartPtr& operator =(SmartPtr& p);
     　　T& operator*() const {return *the_p;}
     　　T* operator->() const {return the_p;}
private:
     　　T *the_p;
}

這只是一個大概的印象，很多東西是可以更改的.

比如可以去掉或加上一些const ，這都需要根據具體的應用環境而定.

注意過載運算子*和->，正是它們使smart pointer看起來跟普通的指標很相像.

而由於smart pointer是一個類，在建構函式、解構函式中都可以通過恰當的程式設計達到一些不錯的效果.
舉例：

比如C++標準庫裡的std::auto_ptr 就是應用很廣的一個例子.

它的實現在不同版本的STL 中雖有不同，但原理都是一樣，大概是下面這個樣子：

template<CLASS&NBSP; X> class auto_ptr
{
public:
     typedef X element_type;
     explicit auto_ptr(X* p = 0) throw():the_p(p) {}
     auto_ptr(auto_ptr& a) throw():the_p(a.release()) {}
     auto_ptr& operator =(auto_ptr& rhs) throw()
     {
           reset(rhs.release());
           return *this;
     }
     ~auto_ptr() throw() {delete the_p;}
     X& operator* () const throw() {return *the_p;}
     X* operator-> () const throw() {return the_p;}
     X* get() const throw() {return the_p;}
     X* release() throw()
     {
           X* tmp = the_p;
           the_p = 0;
           return tmp;

     }
     void reset(X* p = 0) throw()
     {
           if(the_p!=p)
           {
                 delete the_p;
                 the_p = p;
           }
     }
private:
     X* the_p;
};

關於auto_ptr 的使用可以找到很多的列子，這裡不在舉了.

它的主要優點是不用 delete ，可以自動回收已經被分配的空間，由此可以避免資源洩露的問題.

很多Java 的擁護者經常不分黑白的汙衊C++沒有垃圾回收機制，其實不過是貽笑大方而已.

拋開在網上許許多多的商業化和非商業化的C++垃圾回收庫不提， auto_ptr 就足以有效地解決這一問題.

並且即使在產生異常的情況下， auto_ptr 也能正確地回收資源.

這對於寫出異常安全（exception-safe ）的程式碼具有重要的意義.

在使用smart pointer 的過程中，要注意的問題：

針對不同的smart pointer ，有不同的注意事項。比如auto_ptr ，就不能把它用在標準容器裡，因為它只在記憶體中保留一份例項.

把握我前面說的兩個原則：smart pointer 是類而不是指標，是模仿指標，那麼一切問題都好辦.

比如，smart  pointer 作為一個類，那麼以下的做法就可能有問題.

SmartPtr p; 
if(p==0) 
if(!p) 
if(p)

很顯然， p 不是一個真正的指標，這麼做可能出錯.

而SmartPtr 的設計也是很重要的因素.

您可以加上一個bool SmartPtr::null() const 來進行判斷.

如果堅持非要用上面的形式， 那也是可以的,我們就加上operator void* ()試試：

template<CLASS&NBSP; T> class SmartPtr
{
public: ...
     　　operator void*() const {return the_p;}
... private:
     　　T* the_p;
};

這種方法在basic_ios 中就使用過了。這裡也可以更靈活地處理，比如類本身需要operator void*()這樣地操作，

那麼上面這種方法就不靈了。但我們還有過載operator !()等等方法來實現.
總結smart pointer的實質：

smart pointer 的實質就是一個外殼，一層包裝。正是多了這層包裝，我們可以做出許多普通指標無法完成的事，比如前面資源自動回收，或者自動進行引用記數，比如ATL 中CComPtr 和 CComQIPtr 這兩個COM 介面指標類.

然而也會帶來一些副作用，正由於多了這些功能，又會使 smart pointer 喪失一些功能.

WIN結構化異常

對使用WIN32平臺的人來說，對WIN的結構化異常應該要有所瞭解的。WINDOWS的結構化異常是作業系統的一部分，而C++異常只是C++的一部分，當我們用C++編寫程式碼的時候，我們選擇C++的標準異常（也可以用MS VC的異常），編譯器會自動的把我們的C++標準異常轉化成SEH異常。

微軟的Visual C++也支援C + +的異常處理，並且在內部實現上利用了已經引入到編譯程式和Windows作業系統的結構化異常處理的功能。

SEH實際包含兩個主要功能：結束處理（termination handling）和異常處理（exceptionhandling）.

在MS VC的FAQ中有關於SEH的部分介紹，這裡摘超其中的一句：

“在VC5中，增加了新的/EH編譯選項用於控制C++異常處理。C++同步異常處理(/EH)使得編譯器能生成更少的程式碼，/EH也是VC的預設模型。”

一定要記得在背後的事情：在使用SEH的時候，編譯程式和作業系統直接參與了程式程式碼的執行。

Win32異常事件的理解

我寫的另一篇文章：記憶體處理和DLL技術也涉及到了SEH中的異常處理。

Exception（異常處理） 分成軟體和硬體exception2種.如：一個無效的引數或者被0除都會引起軟體exception，而訪問一個尚未commit的頁會引起硬體exception.

發生異常的時候，執行流程終止，同時控制權轉交給作業系統，OS會用上下文（CONTEXT）結構把當前的程式狀態儲存下來，然後就開始search 一個能處理exception的元件，search order如下：

• 首先檢查是否有一個除錯程式與發生exception的程式聯絡在一起，推算這個除錯程式是否有能力處理
• 如上面不能完成，作業系統就在發生exception event的執行緒中search exception event handler
• search與程式關聯在一起的除錯程式
• 系統執行自己的exception event handler code and terminate process

結束處理程式

利用SEH，你可以完全不用考慮程式碼裡是不是有錯誤，這樣就把主要的工作同錯誤處理分離開來.

這樣的分離，可以使你集中精力處理眼前的工作，而將可能發生的錯誤放在後面處理.

微軟在Windows中引入SEH的主要動機是為了便於作業系統本身的開發.

作業系統的開發人員使用SEH，使得系統更加強壯.我們也可以使用SEH，使我們的自己的程式更加強壯.

使用SEH所造成的負擔主要由編譯程式來承擔，而不是由作業系統承擔.

當異常塊（exception block）出現時，編譯程式要生成特殊的程式碼.

編譯程式必須產生一些表（table）來支援處理SEH的資料結構.

編譯程式還必須提供回撥（callback）函式，作業系統可以呼叫這些函式，保證異常塊被處理.

編譯程式還要負責準備棧結構和其他內部資訊，供作業系統使用和參考.

在編譯程式中增加SEH支援不是一件容易的事.

不同的編譯程式廠商會以不同的方式實現SEH，這一點並不讓人感到奇怪.

幸虧我們可以不必考慮編譯程式的實現細節，而只使用編譯程式的SEH功能.

結束處理程式程式碼初步

一個結束處理程式能夠確保去呼叫和執行一個程式碼塊（結束處理程式，termination handler），

而不管另外一段程式碼（保護體， guarded body）是如何退出的。結束處理程式的語法結構如下： __try

{
   file://保護塊
}
__finally
{
  file://結束處理程式
}

在上面的程式碼段中，作業系統和編譯程式共同來確保結束處理程式中的__finally程式碼塊能夠被執行，不管保護體（try塊）是如何退出的。

不論你在保護體中使用return，還是goto，或者是longjump，結束處理程式（finally塊）都將被呼叫。

我們來看一個實列：（返回值：10, 沒有Leak，效能消耗：小）

DWORD Func_SEHTerminateHandle()
{
     DWORD dwReturnData = 0;
     HANDLE hSem = NULL;
     const char* lpSemName = "TermSem";
     hSem =  CreateSemaphore(NULL, 1, 1, lpSemName);
     __try
     {
           WaitForSingleObject(hSem,INFINITE);
           dwReturnData = 5;
     }
     __finally
     {
           ReleaseSemaphore(hSem,1,NULL);
           CloseHandle(hSem);
     }
     dwReturnData += 5;
     return dwReturnData;
}

這段程式碼應該只是做為一個基礎函式，我們將在後面修改它，來看看結束處理程式的作用.

在程式碼加一句：（返回值：5, 沒有Leak，效能消耗：中下）

DWORD Func_SEHTerminateHandle()
{
     DWORD dwReturnData = 0;
     HANDLE hSem = NULL;
     const char* lpSemName = "TermSem";
     hSem =  CreateSemaphore(NULL, 1, 1, lpSemName);
     __try
     {
           WaitForSingleObject(hSem,INFINITE);
           dwReturnData = 5;
           return dwReturnData;
     }
     __finally
     {
           ReleaseSemaphore(hSem,1,NULL);
           CloseHandle(hSem);
     }
     dwReturnData += 5;
     return dwReturnData;
}

在try塊的末尾增加了一個return語句.

這個return語句告訴編譯程式在這裡要退出這個函式並返回dwTemp變數的內容，現在這個變數的值是5.

但是，如果這個return語句被執行，該執行緒將不會釋放信標，其他執行緒也就不能再獲得對信標的控制.

可以想象，這樣的執行次序會產生很大的問題，那些等待信標的執行緒可能永遠不會恢復執行.

通過使用結束處理程式，可以避免return語句的過早執行.

當return語句試圖退出try塊時，編譯程式要確保finally塊中的程式碼首先被執行.

要保證finally塊中的程式碼在try塊中的return語句退出之前執行.

在程式中，將ReleaseSemaphore的呼叫放在結束處理程式塊中，保證信標總會被釋放.

這樣就不會造成一個執行緒一直佔有信標，否則將意味著所有其他等待信標的執行緒永遠不會被分配CPU時間.

在finally塊中的程式碼執行之後，函式實際上就返回.

任何出現在finally塊之下的程式碼將不再執行，因為函式已在try塊中返回,所以這個函式的返回值是5，而不是10.

讀者可能要問編譯程式是如何保證在try塊可以退出之前執行finally塊的.

當編譯程式檢查原始碼時，它看到在try塊中有return語句.

這樣，編譯程式就生成程式碼將返回值（本例中是5）儲存在一個編譯程式建立的臨時變數中.

編譯程式然後再生成程式碼來執行finally塊中包含的指令，這稱為區域性展開.

更特殊的情況是，由於try塊中存在過早退出的程式碼，從而產生區域性展開，導致系統執行finally塊中的內容.

在finally塊中的指令執行之後，編譯程式臨時變數的值被取出並從函式中返回.

可以看到，要完成這些事情，編譯程式必須生成附加的程式碼，系統要執行額外的工作.

在不同的CPU上，結束處理所需要的步驟也不同.

例如，在Alpha處理器上，必須執行幾百個甚至幾千個CPU指令來捕捉try塊中的過早返回並呼叫finally塊.

在編寫程式碼時，就應該避免引起結束處理程式的try塊中的過早退出，因為程式的效能會受到影響.

後面，將討論__leave關鍵字，它有助於避免編寫引起區域性展開的程式碼.

設計異常處理的目的是用來捕捉異常的—不常發生的語法規則的異常情況（在我們的例子中，就是過早返回）.

如果情況是正常的，明確地檢查這些情況，比起依賴作業系統和編譯程式的SEH功能來捕捉常見的事情要更有效.

注意當控制流自然地離開try塊並進入finally塊（就像在Funcenstein1中）時，進入finally塊的系統開銷是最小的.

在x86CPU上使用微軟的編譯程式，當執行離開try塊進入finally塊時，只有一個機器指令被執行，讀者可以在自己的程式中注意到這種系統開銷.

當編譯程式要生成額外的程式碼，系統要執行額外的工作時系統開銷就很值得注意了.

修改程式碼：（返回值：5，沒有Leak，效能消耗：中）

DWORD Func_SEHTerminateHandle()
{
     DWORD dwReturnData = 0;
     HANDLE hSem = NULL;
     const char* lpSemName = "TermSem";
     hSem =  CreateSemaphore(NULL, 1, 1, lpSemName);
     __try
     {
           WaitForSingleObject(hSem,INFINITE);
           dwReturnData = 5;
           if(dwReturnData == 5)
                 goto ReturnValue;
           return dwReturnData;
     }
     __finally
     {
           ReleaseSemaphore(hSem,1,NULL);
           CloseHandle(hSem);
     }
     dwReturnData += 5;
ReturnValue:
     return dwReturnData;
}

程式碼中，當編譯程式看到try塊中的goto語句，它首先生成一個區域性展開來執行finally塊中的內容.

這一次，在finally塊中的程式碼執行之後，在ReturnValue標號之後的程式碼將執行，因為在try塊和finally塊中都沒有返回發生.

這裡的程式碼使函式返回5,而且，由於中斷了從try塊到finally塊的自然流程，可能要蒙受很大的效能損失（取決於執行程式的CPU）

寫上面的程式碼是初步的，現在來看結束處理程式在我們程式碼裡面的真正的價值：

看程式碼：（訊號燈被正常釋放，reserve的一頁記憶體沒有被Free，安全性：安全）

DWORD TermHappenSomeError()
{
     DWORD dwReturnValue = 9;
     DWORD dwMemorySize = 1024;

     char* lpAddress;
     lpAddress = (char*)VirtualAlloc(NULL, dwMemorySize, MEM_RESERVE, PAGE_READWRITE);
}

finally塊的總結性說明

我們已經明確區分了強制執行finally塊的兩種情況：

從try塊進入finally塊的正常控制流.

區域性展開：從try塊的過早退出（goto、longjump、continue、break、return等）強制控制轉移到finally塊.

第三種情況，全域性展開（globalunwind），在發生的時候沒有明顯的標識，我們在本章前面Func_SEHTerminate函式中已經見到.在Func_SEHTerminate的try塊中，有一個對TermHappenSomeError函式的呼叫。TermHappenSomeError函式會引起一個記憶體訪問違規（memory access violation），一個全域性展開會使Func_SEHTerminate函式的finally塊執行.

由於以上三種情況中某一種的結果而導致finally塊中的程式碼開始執行。為了確定是哪一種情況引起finally塊執行，可以呼叫內部函式AbnormalTermination：這個內部函式只在finally塊中呼叫，返回一個Boolean值.指出與finally塊相結合的try塊是否過早退出。換句話說，如果控制流離開try塊並自然進入finally塊，AbnormalTermination將返回FALSE。如果控制流非正常退出try塊—通常由於goto、return、break或continue語句引起的區域性展開，或由於記憶體訪問違規或其他異常引起的全域性展開—對AbnormalTermination的呼叫將返回TRUE。沒有辦法區別finally塊的執行是由於全域性展開還是由於區域性展開.

但這通常不會成為問題，因為可以避免編寫執行區域性展開的程式碼.（注意內部函式是編譯程式識別的一種特殊函式。編譯程式為內部函式產生內聯（inline）程式碼而不是生成呼叫函式的程式碼。例如，memcpy是一個內部函式（如果指定/Oi編譯程式開關）。當編譯程式看到一個對memcpy的呼叫，它直接將memcpy的程式碼插入呼叫memcpy的函式中，而不是生成一個對memcpy函式的呼叫。其作用是程式碼的長度增加了，但執行速度加快了。

在繼續之前，回顧一下使用結束處理程式的理由：

簡化錯誤處理，因所有的清理工作都在一個位置並且保證被執行。

• 提高程式的可讀性。
• 使程式碼更容易維護。
• 如果使用得當，具有最小的系統開銷。

異常處理程式

異常是我們不希望有的事件。在編寫程式的時候，程式設計師不會想去存取一個無效的記憶體地址或用0來除一個數值。不過，這樣的錯誤還是常常會發生的。CPU負責捕捉無效記憶體訪問和用0除一個數值這種錯誤，並相應引發一個異常作為對這些錯誤的反應。CPU引發的異常，就是所謂的硬體異常（hardwareexception）。在本章的後面，我們還會看到作業系統和應用程式也可以引發相應的異常，稱為軟體異常（softwareexception）。

當出現一個硬體或軟體異常時，作業系統嚮應用程式提供機會來考察是什麼型別的異常被引發，並能夠讓應用程式自己來處理異常。下面就是異常處理程式的語法：

__try
{
     //保護塊
}
__except(異常過慮器)
{
     //異常處理程式
}

注意__except關鍵字。每當你建立一個try塊，它必須跟隨一個finally塊或一個except塊。一個try塊之後不能既有finally塊又有except塊。但可以在try-except塊中巢狀try-finally塊，反過來也可以。

異常處理程式程式碼初步

與結束處理程式不同，異常過濾器（exceptionfilter）和異常處理程式是通過作業系統直接執行的，編譯程式在計算異常過濾器表示式和執行異常處理程式方面不做什麼事。

下面幾節的內容舉例說明try-except塊的正常執行，解釋作業系統如何以及為什麼計算異常過濾器，並給出作業系統執行異常處理程式中程式碼的環境。

本來想把程式碼全部寫出來的，但是實在是寫這邊文擋化的時間太長了，所以接下來就只是做說明，而且try和except塊比較簡單。

儘管在結束處理程式的try塊中使用return、goto、continue和break語句是被強烈地反對，但在異常處理程式的try塊中使用這些語句不會產生速度和程式碼規模方面的不良影響。

這樣的語句出現在與except塊相結合的try塊中不會引起區域性展開的系統開銷.

當引發了異常時，系統將定位到except塊的開頭，並計算異常過濾器表示式的值，過濾器表示式的結果值只能是下面三個識別符號之一，這些識別符號定義在windows的Except.h檔案中。識別符號定義為：

EXCEPTION_CONTINUE_EXECUTION(–1) //  Exception is dismissed. Continue execution at the point where the exception occurred.
EXCEPTION_CONTINUE_SEARCH(0)  // Exception is not recognized. Continue to search up the stack for a handler, first for containing try-except statements, then for handlers with the next highest precedence.
EXCEPTION_EXECUTE_HANDLER(1)  // Exception is recognized. Transfer control to the exception handler by executing the __except compound statement, then continue execution at the assembly instruction that was executing when the exception was raised

下面將討論這些識別符號如何改變執行緒的執行。

下面的流程概括了系統如何處理一個異常的情況：(這裡的流程假設是正向的)

*****開始 -> 執行一個CPU指令 -> {是否有異常被引發} -> 是 -> 系統確定最裡層的try 塊 -> {這個try塊是否有一個except塊} -> 是 -> {過濾器表示式的值是什麼} ->異常執行處理程式 -> 全域性展開開始 -> 執行except塊中的程式碼 -> 在except塊之後執行繼續*****

EXCEPTION_EXECUTE_HANDLER

在異常過濾器表示式的值如果是EXCEPTION_EXECUTE_HANDLER，這個值的意思是要告訴系統：“我認出了這個異常.

即，我感覺這個異常可能在某個時候發生，我已編寫了程式碼來處理這個問題，現在我想執行這個程式碼”

在這個時候，系統執行一個全域性展開，然後執行向except塊中程式碼（異常處理程式程式碼）的跳轉.

在except塊中程式碼執行完之後，系統考慮這個要被處理的異常並允許應用程式繼續執行。這種機制使windows應用程式可以抓住錯誤並處理錯誤，再使程式繼續執行，不需要使用者知道錯誤的發生。但是，當except塊執行後，程式碼將從何處恢復執行？稍加思索，我們就可以想到幾種可能性:

第一種可能性是從產生異常的CPU指令之後恢復執行。這看起來像是合理的做法，但實際上，很多程式的編寫方式使得當前面的指令出錯時，後續的指令不能夠繼續成功地執行。

程式碼應該儘可能地結構化，這樣，在產生異常的指令之後的CPU指令有望獲得有效的返回值。例如，可能有一個指令分配記憶體，後面一系列指令要執行對該記憶體的操作。

如果記憶體不能夠被分配，則所有後續的指令都將失敗，上面這個程式重複地產生異常。

所幸的是，微軟沒有讓系統從產生異常的指令之後恢復指令的執行。這種決策使我們免於面對上面的問題。

第二種可能性是從產生異常的指令恢復執行。這是很有意思的可能性。

如果在except塊中有這樣的語句會怎麼樣呢：在except塊中有了這個賦值語句，可以從產生異常的指令恢復執行。

這一次，執行將繼續，不會產生其他的異常。可以做些修改，讓系統重新執行產生異常的指令。

你會發現這種方法將導致某些微妙的行為。我們將在EXCEPTION_CONTINUE_EXECUTION一節中討論這種技術。

第三種可能性是從except塊之後的第一條指令開始恢復執行。這實際是當異常過濾器表示式的值為EXCEPTION_EXECUTE_HANDLER時所發生的事。在except塊中的程式碼結束執行後，控制從except塊之後的第一條指令恢復。

c++異常引數傳遞

從語法上看，在函式裡宣告引數與在catch子句中宣告引數是一樣的，catch裡的引數可以是值型別，引用型別，指標型別.例如：

try
{
     .....
}
catch(A a)
{
     .....
}
catch(B& b)
{
     .....
}
catch(C* c)
{
     .....
}

儘管表面是它們是一樣的，但是編譯器對二者的處理卻又很大的不同.

呼叫函式時，程式的控制權最終還會返回到函式的呼叫處，但是丟擲一個異常時，控制權永遠不會回到丟擲異常的地方.

class A;
void func_throw()
{
     A a;
     throw a;  //丟擲的是a的拷貝，拷貝到一個臨時物件裡
}
try
{
     func_throw();
}
catch(A a)  //臨時物件的拷貝
{
     ...
}

當我們丟擲一個異常物件時，丟擲的是這個異常物件的拷貝。當異常物件被拷貝時，拷貝操作是由物件的拷貝建構函式完成的.

該拷貝建構函式是物件的靜態型別(static type)所對應類的拷貝建構函式，而不是物件的動態型別(dynamic type)對應類的拷貝建構函式。此時物件會丟失RTTI資訊.

異常是其它物件的拷貝，這個事實影響到你如何在catch塊中再丟擲一個異常。比如下面這兩個catch塊，乍一看好像一樣:

catch(A& w)  // 捕獲異常
{
     　// 處理異常
     　throw; // 重新丟擲異常，讓它繼續傳遞
}
catch(A& w)  // 捕獲Widget異常
{
     　// 處理異常
     　throw w; // 傳遞被捕獲異常的拷貝
}

第一個塊中重新丟擲的是當前異常(current exception),無論它是什麼型別。（有可能是A的派生類）

第二個catch塊重新丟擲的是新異常，失去了原來的型別資訊.

一般來說，你應該用throw來重新丟擲當前的異常，因為這樣不會改變被傳遞出去的異常型別，而且更有效率，因為不用生成一個新拷貝.

看看以下這三種宣告:

catch (A w) ... // 通過傳值
catch (A& w) ... // 通過傳遞引用
catch (const A& w) ... //const引用

一個被異常丟擲的物件(總是一個臨時物件)可以通過普通的引用捕獲;它不需要通過指向const物件的引用(reference-to-const)捕獲.

在函式呼叫中不允許轉遞一個臨時物件到一個非const引用型別的引數裡，但是在異常中卻被允許.

回到異常物件拷貝上來,我們知道，當用傳值的方式傳遞函式的引數，我們製造了被傳遞物件的一個拷貝，並把這個拷貝儲存到函式的引數裡.

同樣我們通過傳值的方式傳遞一個異常時，也是這麼做的當我們這樣宣告一個catch子句時:
catch (A w) … // 通過傳值捕獲

會建立兩個被丟擲物件的拷貝，一個是所有異常都必須建立的臨時物件，第二個是把臨時物件拷貝進w中。實際上，編譯器會優化掉一個拷貝。同樣，當我們通過引用捕獲異常時，

catch (A& w) … // 通過引用捕獲
catch (const A& w) … //const引用捕獲

這仍舊會建立一個被丟擲物件的拷貝:拷貝是一個臨時物件。相反當我們通過引用傳遞函式引數時，沒有進行物件拷貝.

話雖如此，但是不是所有編譯器都如此,VS200就表現很詭異.

通過指標丟擲異常與通過指標傳遞引數是相同的.

不論哪種方法都是一個指標的拷貝被傳遞,你不能認為丟擲的指標是一個指向區域性物件的指標，因為當異常離開區域性變數的生存空間時，該區域性變數已經被釋放.

Catch子句將獲得一個指向已經不存在的物件的指標。這種行為在設計時應該予以避免.

另外一個重要的差異是在函式呼叫者或丟擲異常者與被呼叫者或異常捕獲者之間的型別匹配的過程不同.

在函式傳遞引數時，如果引數不匹配，那麼編譯器會嘗試一個型別轉換，如果存在的話。而對於異常處理的話，則完全不是這樣。見一下的例子：

void func_throw()
{
     CString a;
     throw a;  //丟擲的是a的拷貝，拷貝到一個臨時物件裡
}
try
{
     func_throw();
}
catch(const char* s)
{
     ...
}

丟擲的是CString，如果用const char*來捕獲的話，是捕獲不到這個異常的.

儘管如此，在catch子句中進行異常匹配時可以進行兩種型別轉換.第一種是基類與派生類的轉換，一個用來捕獲基類的catch子句也可以處理派生類型別的異常.

反過來，用來捕獲派生類的無法捕獲基類的異常.

第二種是允許從一個型別化指標(typed pointer)轉變成無型別指標(untyped pointer)，所以帶有const void* 指標的catch子句能捕獲任何

型別的指標型別異常:

catch (const void*) … //可以捕獲所有指標異常

另外，你還可以用catch(…)來捕獲所有異常，注意是三個點.

傳遞引數和傳遞異常間最後一點差別是catch子句匹配順序總是取決於它們在程式中出現的順序.

因此一個派生類異常可能被處理其基類異常的catch子句捕獲，這叫異常截獲，一般的編譯器會有警告.

class A
{
public:
     A()
     {
           cout << "class A creates" << endl;
     }
     void print()
     {
           cout << "A" << endl;
     }
     ~A()
     {
           cout << "class A destruct" << endl;
     }
};
class B: public A
{
public:
     B()
     {
           cout << "class B create" << endl;
     }
     void print()
     {
           cout << "B" << endl;
     }
     ~B()
     {
           cout << "class B destruct" << endl;
     }
};
void func()
{
     B b;
     throw b;
}
try
{
     func();
}
catch(B& b)  //必須將B放前面，如果把A放前面，B放後面，那麼B型別的異常會先被截獲。
{
     b.print();
}
catch(A& a)
{
     a.print() ;
}

相反的是，當你呼叫一個虛擬函式時，被呼叫的函式位於與發出函式呼叫的物件的動態型別(dynamic type)最相近的類裡.
你可以這樣說虛擬函式匹配採用最優匹配法，而異常處理匹配採用的是最先匹配法.附：
異常的描述
函式和函式可能丟擲的異常集合作為函式宣告的一部分是有價值的，例如

void f(int a) throw(x2,x3);

表示f()只能丟擲兩個異常x2,x3,以及這些型別派生的異常，但不會丟擲其他異常.

如果f函式違反了這個規定，丟擲了x2,x3之外的異常,例如x4,那麼當函式f丟擲x4異常時，

會轉換為一個std::unexpected()呼叫，預設是呼叫std::terminate(),通常是呼叫abort().

如果函式不帶異常描述，那麼假定他可能丟擲任何異常,例如:

int f();  //可能丟擲任何異常

不帶任何異常的函式可以用空表表示:

int g() throw();  // 不會丟擲任何異常