異常處理 (轉)[@more@]

C++ Exception Handler
2001-12-11

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

也許我們已經使用過異常，但是你會是一種習慣嗎，不要老是想著當我開啟一個的時候才用異常判斷一下，我知道對你來說你喜歡用return value或者是print error message來做，你想過這樣做會導致Memory Leak，退出，程式碼重複/難讀，垃圾一堆…..嗎？現在的已經是n*365*24小時的執行了，軟體的健壯已經是一個很要考慮的時候了。
自序：
對寫程式來說異常真的是很重要，一個穩健的程式碼不是靠返回Error Message/return Value來解決的，可是往往我們從C走過來，習慣了這樣的方式。
僅以本文獻給今天將要來臨的流星雨把，還好我能在今天白天把這寫完，否則會是第4個通宵了；同時感謝Jeffrey大師，沒有他的SEH理論這篇文章只能完成一半，而且所有SEH列子的構想都來自他的指導；另外要感謝tt Meyers大師，我是看他的書長大的；還要感謝Adamc / Darwin / Julian ，當然還有Nick的Coffee

內容導讀：
（請開啟文件結構圖來讀這篇文章。）
本文包括2個大的異常實現概念：C++的標準異常和SHE異常。

C++標準異常：也許我們瞭解過他，但你有考慮過，其實你根本不會使用，你不相信，那我問你：垃圾回收在C++中怎麼實現？其實不需要實現，C++已經有了，但是你不會用，那麼從開始看把。也許很高興看到錯誤之後的Heap/Stack中被釋放，可是如果沒有呢？有或者試想一下一個能解決的錯誤，需要我們把整個程式Kill掉嗎？
在C++標準異常中我向你推薦這幾章：以及一個深點的

SHE異常：我要問你你是一個程式設計師嗎？如果不是，那麼也許你真的不需要看
這塊內容了，SHE是的結構化異常，每一個WIN32程式設計師都應該要掌握它。SHE功能強大，包括Tenation handling和Exception handling兩大部分，強有力的維護了程式碼的健壯，雖然要以部分系統做犧牲(其實可以避免)。在SHE中有大量的程式碼，已經在Win平臺上測試過了。
這裡要提一下：在__finally處理中參與了絕大多數的工作，而Exception則是OS接管了幾乎所有的工作，也許我沒有提到的是：對__finally來說當遇到ExitThread/ExitProcess/abort等函式時，finally塊不會被。另，我們的程式碼使用軟體異常是比return error message好2**32的方法。

另，《使用解構函式防止資源洩漏》這個節點引用了More effective C++的條款9，用2個列子，講述了我們一般都會犯下的錯誤，往往這種錯誤是我們沒有意識到的但確實是會給我們的軟體帶來致命的Leak/Crash，但這是有解決的方法的，那就是使用“靈巧指標”。

如果對照的37條條款，關於異常的高階使用，有以下內容是沒有完成的：
l 使用建構函式防止資源Leak（More effective C++ #10）
l 禁止異常資訊傳遞到析構Function外 (More effective C++ #11)
l 透過引用捕獲異常（More effective C++ #13）
l 謹慎使用異常規格（More effective C++ #14）
l 瞭解異常處理造成的系統開銷（More effective C++ #15）
l 限制物件數量（More effective C++ #26）
l 靈巧指標（More effective C++ #28）
[宣告：節點：和節點：中有大量的關於More effective C++的條款，所以本文擋只用於自我閱讀和內部交流，任何公開化和商業化，事先宣告與本人無關。]

C++異常
C++引入異常的原因
C++新增的異常機制改變了某些事情，這些改變是徹底的，但這些改變也可能讓我們不舒服。例如使用未經處理的pointer變的很危險，Memory/Re Leak變的更有可能了（別說什麼Memory便宜了，那不是一個優秀的程式設計師說的話。），寫出一個具有你希望的行為的建構函式和解構函式也變的困難（不可預測），當然最危險的也許是我們寫出的東東狗屁了，或者是速度變慢了。

大多數的程式設計師知道Howto use exception 來處理我們的程式碼，可是很多人並不是很重視異常的處理（國外的很多Code倒是處理的很好，的Exception機制很不錯）。異常處理機制是解決某些問題的上佳辦法，但同時它也引入了許多隱藏的控制流程；有時候，要正確無誤的使用它並不容易。

在異常被throw後，沒有一個方法能夠做到使軟體的行為具有可預測性和可靠性（這句話不是我說的，是Jack Reeves寫的Co with Exception和Herb Sutter寫的Exception-Safe Generic Containers中的。）一個沒有按照異常設計的程式想Run 正常，是做夢，別去想沒有異常出現的可能，

對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
class ExceptionClass{
char* name;
public:
ExceptionClass(const char* name="default name")
{
cout< this->name=name;
}
~ExceptionClass()
{
cout<}
void mythrow()
{
throw ExceptionClass("my throw");
}
}

void main(){
ExceptionClass e("Test");
try{
e.mythrow();
}
catch(...)
{
cout< }
}
這是輸出資訊：
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< }
~ExceptionClass(){
cout< }
void ReportError() {
cout< }
};

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

_tmain()
{
ArguClass e("haha");
try {
e.mythrow();
}
catch(int)
{
cout< }
catch(ExceptionClass pTest)
{
pTest.ReportError();
}
catch(...){
cout< }
}
輸出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
#include

class ExceptionClass1
{
char* s;
public:
ExceptionClass1(){
cout< s=new char[4];
cout< throw 18;
}
~ExceptionClass1(){
cout< 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派生的異常類

ain_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 ），並且在它的解構函式里刪除這個物件。下面所示的是auto_ptr類的一些重要的部分：

template

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 auto_ptr {
public:
typedef T element_type;
explicit auto_ptr(T *p = 0) throw();
auto_ptr(const auto_ptr& rhs) throw();
auto_ptr& operator=(auto_ptr& 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 pa(readALA(dataSource));

　　pa->processAdoption();

　}

這個版本的processAdoptions在兩個方面區別於原來的processAdoptions函式。
第一， pa被宣告為一個auto_ptr物件，而不是一個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) ... 透過引用捕獲
這仍舊會建立一個被丟擲物件的複製：複製是一個臨時物件。相反當我們透過引用傳遞函式引數時，沒有進行物件複製。當丟擲一個異常時，系統構造的（以後會析構掉）被丟擲物件的複製數比以相同物件做為引數傳遞給函式時構造的複製數要多一個。

我們還沒有討論透過指標丟擲異常的情況，不過透過指標丟擲異常與透過指標傳遞引數是相同的。不論哪種方法都是一個指標的複製被傳遞。你不能認為丟擲的指標是一個指向區域性物件的指標，因為當異常離開區域性變數的生存空間時，該區域性變數已經被釋放。Catch子句將獲得一個指向已經不存在的物件的指標。這種行為在設計時應該予以避免。

物件從函式的呼叫處傳遞到函式引數裡與從異常丟擲點傳遞到catch子句裡所採用的方法不同，這只是引數傳遞與異常傳遞的區別的一個方面，第二個差異是在函式呼叫者或丟擲異常者與被呼叫者或異常捕獲者之間的型別匹配的過程不同。比如在標準數學庫（the standard math library）中sqrt函式：

double sqrt(double); // from or
我們能這樣計算一個整數的平方根，如下所示：

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*, or
// overflow_error*

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

catch (const void*) ... 獲任何指標型別異常

傳遞引數和傳遞異常間最後一點差別是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 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 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 SmartPtr {
public: ...
operator void*() const {return the_p;}
... private:
T* the_p;
};
這種方法在basic_i中就使用過了。這裡也可以更靈活地處理，比如類本身需要operator void*()這樣地操作，那麼上面這種方法就不靈了。但我們還有過載operator !()等等方法來實現。

總結smart pointer的實質：
smart pointer 的實質就是一個外殼，一層包裝。正是多了這層包裝，我們可以做出許多普通指標無法完成的事，比如前面資源自動回收，或者自動進行引用記數，比如ATL 中CComPtr 和 CComQIPtr 這兩個介面指標類。然而也會帶來一些副作用，正由於多了這些功能，又會使 smart pointer 喪失一些功能。

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

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

S E H實際包含兩個主要功能：結束處理（ termination handling）和異常處理（ e x c e p t i o nh a n d l i n g）。

在MS VC的FAQ中有關於SHE的部分介紹，這裡摘超其中的一句：
“在VC5中，增加了新的/EH編譯選項用於控制C++異常處理。C++同步異常處理(/EH)使得編譯器能生成更少的程式碼，/EH也是VC的預設模型。”

一定要記得在背後的事情：在使用SHE的時候，編譯程式和作業系統直接參與了程式程式碼的執行。
Win32異常事件的理解
我寫的另一篇文章：記憶體處理和DLL技術也涉及到了SHE中的異常處理。

Exception（異常處理）分成軟體和exception 2種。如：一個無效的引數或者被0除都會引起軟體exception，而訪問一個尚未commit的頁會引起硬體exception.
發生異常的時候，執行流程終止，同時控制權轉交給作業系統，OS會用上下文（CONTEXT）結構把當前的程式狀態儲存下來，然後就開始search 一個能處理exception的，search order如下：
1、首先檢查是否有一個程式與發生exception的程式聯絡在一起，推算這個除錯程式是否有能力處理
2、如上面不能完成，作業系統就在發生exception event的執行緒中search exception event handler
3、 search與程式關聯在一起的除錯程式
4、系統執行自己的exception event handler code and terminate process

結束處理程式
利用S E H，你可以完全不用考慮程式碼裡是不是有錯誤，這樣就把主要的工作同錯誤處理分離開來。這樣的分離，可以使你集中精力處理眼前的工作，而將可能發生的錯誤放在後面處理。

微軟在Wi n d o w s中引入S E H的主要動機是為了便於作業系統本身的開發。作業系統的開發人員使用S E H，使得系統更加強壯。我們也可以使用S E H，使我們的自己的程式更加強壯。

使用S E H所造成的負擔主要由編譯程式來承擔，而不是由作業系統承擔。
當異常塊（exception block）出現時，編譯程式要生成特殊的程式碼。編譯程式必須產生一些表（ t a b l e）來支援處理S E H的資料結構。
編譯程式還必須提供回撥（ c a l l b a c k）函式，作業系統可以呼叫這些函式，保證異常塊被處理。
編譯程式還要負責準備棧結構和其他內部資訊，供作業系統使用和參考。
在編譯程式中增加S E H支援不是一件容易的事。不同的編譯程式廠商會以不同的方式實現S E H，這一點並不讓人感到奇怪。幸虧我們可以不必考慮編譯程式的實現細節，而只使用編譯程式的S E H功能。（其實大多數編譯程式廠商都採用微軟建議的語法）

結束處理程式程式碼初步
一個結束處理程式能夠確保去呼叫和執行一個程式碼塊（結束處理程式，termination handler），
而不管另外一段程式碼（保護體， guarded body）是如何退出的。結束處理程式的語法結構如下：
__try
{
護塊
}
__finally
{
束處理程式
}
在上面的程式碼段中，作業系統和編譯程式共同來確保結束處理程式中的__f i n a l l y程式碼塊能夠被執行，不管保護體（t r y塊）是如何退出的。不論你在保護體中使用r e t u r n，還是g o t o，或者是longjump，結束處理程式（f i n a l l y塊）都將被呼叫。

=====================
************************
我們來看一個實列：（返回值：10, 沒有Leak，效能消耗：小）
D 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;
}
在t r y塊的末尾增加了一個r e t u r n語句。這個r e t u r n語句告訴編譯程式在這裡要退出這個函式並返回d w Te m p變數的內容，現在這個變數的值是5。但是，如果這個r e t u r n
語句被執行，該執行緒將不會釋放信標，其他執行緒也就不能再獲得對信標的控制。可以想象，這樣的執行次序會產生很大的問題，那些等待信標的執行緒可能永遠不會恢復執行。

透過使用結束處理程式，可以避免r e t u r n語句的過早執行。當r e t u r n語句試圖退出t r y塊時，編譯程式要確保f i n a l l y塊中的程式碼首先被執行。要保證f i n a l l y塊中的程式碼在t r y塊中的r e t u r n語句退出之前執行。在程式中，將R e l e a s e S e m a p h o r e的呼叫放在結束處理程式塊中，保證信標總會被釋放。這樣就不會造成一個執行緒一直佔有信標，否則將意味著所有其他等待信標的執行緒永遠不會被分配C P U時間。

在f i n a l l y塊中的程式碼執行之後，函式實際上就返回。任何出現在f i n a l l y塊之下的程式碼將不再執行，因為函式已在t r y塊中返回。所以這個函式的返回值是5，而不是10。

讀者可能要問編譯程式是如何保證在t r y塊可以退出之前執行f i n a l l y塊的。當編譯程式檢查原始碼時，它看到在t r y塊中有r e t u r n語句。這樣，編譯程式就生成程式碼將返回值（本例中是5）儲存在一個編譯程式建立的臨時變數中。編譯程式然後再生成程式碼來執行f i n a l l y塊中包含的指令，這稱為區域性展開。更特殊的情況是，由於t r y塊中存在過早退出的程式碼，從而產生區域性展開，導致系統執行f i n a l l y塊中的內容。在f i n a l l y塊中的指令執行之後，編譯程式臨時變數的值被取出並從函式中返回。

可以看到，要完成這些事情，編譯程式必須生成附加的程式碼，系統要執行額外的工作。在
不同的C P U上，結束處理所需要的步驟也不同。例如，在A l p h a上，必須執行幾百個甚至幾千個C P U指令來捕捉t r y塊中的過早返回並呼叫f i n a l l y塊。在編寫程式碼時，就應該避免引起結束處理程式的t r y塊中的過早退出，因為程式的效能會受到影響。

後面，將討論_ _ l e a v e關鍵字，它有助於避免編寫引起區域性展開的程式碼。

設計異常處理的目的是用來捕捉異常的—不常發生的語法規則的異常情況（在我們的例子中，就是過早返回）。如果情況是正常的，明確地檢查這些情況，比起依賴作業系統和編譯程式的S E H功能來捕捉常見的事情要更有效。
注意當控制流自然地離開t r y塊並進入f i n a l l y塊（就像在F u n c e n s t e i n 1中）時，進入f i n a l l y塊的系統開銷是最小的。在x86 上使用微軟的編譯程式，當執行離開try 塊進入f i n a l l y塊時，只有一個機器指令被執行，讀者可以在自己的程式中注意到這種系統開銷。當編譯程式要生成額外的程式碼，系統要執行額外的工作時系統開銷就很值得注意了
========================
修改程式碼：（返回值：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;
}
程式碼中，當編譯程式看到t r y塊中的g o t o語句，它首先生成一個區域性展開來執行f i n a l l y塊中的內容。這一次，在f i n a l l y塊中的程式碼執行之後，在R e t u r n Va l u e標號之後的程式碼將執行，因為在t r y塊和f i n a l l y塊中都沒有返回發生。這裡的程式碼使函式返回5。而且，由於中斷了從t r y塊到f i n a l l y塊的自然流程，可能要蒙受很大的效能損失（取決於執行程式的C P U）
*************************
=====================
寫上面的程式碼是初步的，現在來看結束處理程式在我們程式碼裡面的真正的價值：
看程式碼：（訊號燈被正常釋放，reserve的一頁記憶體沒有被Free，安全性：安全）
DWORD TermHappenSomeError()
{
DWORD dwReturnValue = 9;
DWORD dwMemorySize = 1024;

char* lpAddress;
lpAddress = (char*)VirtualAlloc(NULL, dwMemorySize, MEM_RESERVE, PAGE_READWRITE);
*lpAddress = 'A'; //

VirtualFree((LPVOID)lpAddress, 1024, MEM_RELEASE);
return dwReturnValue;
}

DWORD Func_SEHTerminate()
{
DWORD dwReturnData = 0;
HANDLE hSem = NULL;
const char* lpSemName = "TermSem";
hSem = CreateSemaphore(NULL, 1, 1, lpSemName);

__try
{
WaitForSingleObject(hSem,INFINITE);
dwReturnData = TermHappenSomeError();
}
__finally
{
ReleaseSemaphore(hSem,1,NULL);
CloseHandle(hSem);
}
return dwReturnData;
}
在上面的程式碼中，我們看到TermHappenSomeError()函式包含一個錯誤（對沒有Commit的頁進行提交），會引起一個無效記憶體訪問。如果沒有S E H，在這種情況下，將會給顯示一個很常見的Application Error對話方塊。當使用者忽略這個錯誤對話方塊，該程式就結束了。當這個程式結束（由於一個無效記憶體訪問），信標仍將被佔用並且永遠不會被釋放，這時候，任何等待信標的其他程式中的執行緒將不會被分配C P U時間。但若將對R e l e a s e S e m a p h o r e的呼叫放在f i n a l l y塊中，就可以保證信標獲得釋放，即使某些其他函式會引起記憶體訪問錯誤。

如果結束處理程式足夠強，能夠捕捉由於無效記憶體訪問而結束的程式，我們就可以相信它也能夠捕捉s e t j u m p和l o n g j u m p的結合，還有那些簡單語句如b r e a k和c o n t i n u e。
=======================
下面是一個非常有挑戰性的程式碼，但是這段程式碼在現實程式設計中，我相信沒有程式設計師會寫這麼無聊的程式碼段。
程式碼：（返回值：14）
DWORD Func_SEHTerminateHard()
{
DWORD dwTemp = 0;
while(dwTemp < 10)
{
__try
{
if(dwTemp == 2)
continue;
if(dwTemp == 3)
break;
}
__finally
{
dwTemp++;
}
dwTemp++;
}
dwTemp += 10;

return dwTemp;
}
我們來一步一步地分析函式做了什麼。首先d w Te m p被設定成0。t r y塊中的程式碼執行，但兩個i f語句的值都不為T R U E。執行自然移到f i n a l l y塊中的程式碼，在這裡d w Te m p增加到1。然後f i n a l l y塊之後的指令又增加d w Te m p，使它的值成為2，當迴圈繼續，d w Te m p為2，t r y塊中的c o n t i n u e語句將被執行。如果沒有結束處理程式在從t r y塊中退出之前強制執行f i n a l l y塊，執行就立即跳回w h i l e測試，d w Te m p不會被改變，將出現無限（死）迴圈。利用一個結束處理程式，系統知道c o n t i n u e語句要引起控制流過早退出t r y塊，而將執行移到f i n a l l y塊。在f i n a l l y塊中，d w Te m p被增加到3。但f i n a l l y塊之後的程式碼不執行，因為控制流又返回到c o n t i n u e，再到迴圈的開頭。現在我們處理迴圈的第三次重複。這一次，第一個i f語句的值是FA L S E，但第二個語句的值是T R U E。系統又能夠捕捉要跳出t r y塊的企圖，並先執行f i n a l l y塊中的程式碼。現在d w Te m p增加到4。由於b r e a k語句被執行，迴圈之後程式部分的控制恢復。這樣， f i n a l l y塊之後的迴圈中的程式碼沒有執行。迴圈下面的程式碼對d w Te m p增加1 0，這時d w Te m p的值是1 4，這就是呼叫這個函式的結果。

儘管結束處理程式可以捕捉t r y塊過早退出的大多數情況，但當執行緒或程式被結束時，它不能引起f i n a l l y塊中的程式碼執行。當呼叫E x i t T h r e a d或E x i t P r o c e s s時，將立即結束執行緒或程式，而不會執行f i n a l l y 塊中的任何程式碼。另外，如果由於某個程式呼叫Te r m i n a t e T h r e a d或Te r m i n a t e P r o c e s s，執行緒或程式將死掉， f i n a l l y塊中的程式碼也不執行。某些C執行期函式（例如a b o r t）要呼叫E x i t P r o c e s s，也使f i n a l l y塊中的程式碼不能執行。雖然沒有辦法阻止其他程式結束你的一個執行緒或程式，但你可以阻止你自己過早呼叫E x i t T h r e a d和E x i t P r o c e s s。

========================
回到我們的基本函式，我們對它進行修改，接下來的程式碼是：（返回值：100）
DWORD Func_SEHTerminateMReturn()
{
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);
return (DWORD)100;
}

dwReturnData = 10;
return dwReturnData;
}
t r y塊將要執行，並試圖將dwReturnData的值（5）返回給這個函式的呼叫者。前面已經說過，試圖從t r y塊中過早的返回將導致產生程式碼，把返回值置於由編譯程式建立的臨時變數中。然後， f i n a l l y塊中的程式碼被執行。在這裡， f i n a l l y塊中增加了一個r e t u r n語句。那麼返回5還是1 0 0？這裡的答案是1 0 0，因f i n a l l y塊中的r e t u r n語句引起值1 0 0儲存在值5所儲存的臨時變數中，覆蓋了值5。當f i n a l l y塊完成執行，現在臨時變數中的值（ 1 0 0）從函式返回給呼叫程式。

我們已經看到結束處理程式在補救t r y塊中的過早退出的執行方面很有效，但也看到結束處理程式由於要阻止t r y塊的過早退出而產生了我們不希望有的結果。更好的辦法是在結束處理程式的t r y塊中避免任何會引起過早退出的語句。實際上，最好將r e t u r n、c o n t i n u e、b r e a k、g o t o等語句從結束處理程式的t r y塊和f i n a l l y塊中移出去，放在結束處理程式的外面。這樣做會使編譯程式產生較小的程式碼，因為不需要再捕捉t r y塊中的過早退出，也使編譯程式產生更快的程式碼（因為執行區域性展開的指令也少）。另外，程式碼也更容易閱讀和維護

應用結束處理程式程式設計
我們已經談過了結束處理程式的基本語法和語意。現在看一看如何用結束處理程式來簡化
一個更復雜的程式設計問題。先看一個完全沒有利用結束處理程式的函式：
（唉~~~~~~~~~~~~各位大哥，我實在吃不消打了，所以程式碼我就不paste上來了，在這裡我只說說注意點和程式設計規範。）

在程式設計中，有很多人往往喜歡用錯誤判斷，這樣造成的後果是程式碼的可讀性很差，程式碼難以維護，所以我們使用結束處理程式的真正好處是函式的所有清理（ c l e a n u p）程式碼都區域性化在一個地方且只在一個地方： f i n a l l y塊。如果需要在這個函式中再增加條件程式碼，只需在f i n a l l y塊中簡單地增加一個清理行，不需要回到每個可能失敗的地方新增清理程式碼

但是我們已經發現和證實了，如果我們在__try塊中使用到了return等跳轉語句的時候，系統開銷這個問題就產生了。為了幫助避免在t r y塊中使用r e t u r n語句，微軟在其C / C + +編譯程式中增加了另一個關鍵字__l e a v e。(自己看MSDN把)

在t r y塊中使用 l e a v e關鍵字會引起跳轉到t r y塊的結尾。可以認為是跳轉到t r y塊的右大括號。由於控制流自然地從t r y塊中退出並進入f i n a l l y塊，所以不產生系統開銷。當按照這種方式利用結束處理程式來設計函式時，要記住在進入t r y塊之前，要將所有資源控制程式碼初始化為無效的值。然後，在f i n a l l y塊中，檢視哪些資源被成功的分配，就可以知道哪些要釋放。另外一種確定需要釋放資源的辦法是對成功分配的資源設定一個標誌。然後， f i n a l l y塊中的程式碼可以檢查標誌的狀態，來確定資源是否要釋放。

finally塊的總結性說明
我們已經明確區分了強制執行f i n a l l y塊的兩種情況：
• 從t r y塊進入f i n a l l y塊的正常控制流。
• 區域性展開：從t r y塊的過早退出（g o t o、l o n g j u m p、c o n t i n u e、b r e a k、r e t u r n等）強制控制轉移到f i n a l l y塊。
第三種情況，全域性展開（ global unwind），在發生的時候沒有明顯的標識，我們在本章前面Func_SEHTerminate函式中已經見到。在Func_SEHTerminate的t r y塊中，有一個對TermHappenSomeError函式的呼叫。TermHappenSomeError函式會引起一個記憶體訪問違規（ memory access violation ），一個全域性展開會使Func_SEHTerminate函式的f i n a l l y塊執行。

由於以上三種情況中某一種的結果而導致f i n a l l y塊中的程式碼開始執行。為了確定是哪一種情況引起f i n a l l y塊執行，可以呼叫內部函式AbnormalTermination：這個內部函式只在f i n a l l y塊中呼叫，返回一個B o o l e a n值。指出與f i n a l l y塊相結合的t r y塊是否過早退出。換句話說，如果控制流離開t r y塊並自然進入f i n a l l y塊，AbnormalTermination將返回FA L S E。如果控制流非正常退出t r y塊—通常由於g o t o、r e t u r n、b r e a k或c o n t i n u e語句引起的區域性展開，或由於記憶體訪問違規或其他異常引起的全域性展開—對AbnormalTermination的呼叫將返回T R U E。沒有辦法區別f i n a l l y塊的執行是由於全域性展開還是由於區域性展開。但這通常不會成為問題，因為可以避免編寫執行區域性展開的程式碼。（注意內部函式是編譯程式識別的一種特殊函式。編譯程式為內部函式產生內聯（i n l i n e）程式碼而不是生成呼叫函式的程式碼。例如， m e m c p y是一個內部函式（如果指定/ O i編譯程式開關）。當編譯程式看到一個對m e m c p y的呼叫，它直接將m e m c p y的程式碼插入呼叫m e m c p y的函式中，而不是生成一個對m e m c p y函式的呼叫。其作用是程式碼的長度增加了，但執行速度加快了。

在繼續之前，回顧一下使用結束處理程式的理由：
• 簡化錯誤處理，因所有的清理工作都在一個位置並且保證被執行。
• 提高程式的可讀性。
• 使程式碼更容易維護。
• 如果使用得當，具有最小的系統開銷。

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

當出現一個硬體或軟體異常時，作業系統嚮應用程式提供機會來考察是什麼型別的異常被引發，並能夠讓應用程式自己來處理異常。下面就是異常處理程式的語法：
__try
{
護塊
}
__except(異常過慮器)
{
常處理程式
}
注意__ e x c e p t關鍵字。每當你建立一個t r y塊，它必須跟隨一個f i n a l l y塊或一個e x c e p t塊。一個try 塊之後不能既有f i n a l l y塊又有e x c e p t塊。但可以在t r y - e x c e p t塊中巢狀t r y - f i n a l l y塊，反過來也可以。

異常處理程式程式碼初步
與結束處理程式不同，異常過濾器（ exception filter）和異常處理程式是透過作業系統直接執行的，編譯程式在計算異常過濾器表示式和執行異常處理程式方面不做什麼事。下面幾節的內容舉例說明t r y - e x c e p t塊的正常執行，解釋作業系統如何以及為什麼計算異常過濾器，並給出作業系統執行異常處理程式中程式碼的環境。

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

儘管在結束處理程式的t r y塊中使用r e t u r n、g o t o、c o n t i n u e和b r e a k語句是被強烈地反對，但在異常處理程式的t r y塊中使用這些語句不會產生速度和程式碼規模方面的不良影響。這樣的語句出現在與e x c e p t塊相結合的t r y塊中不會引起區域性展開的系統開銷

當引發了異常時，系統將定位到e x c e p t塊的開頭，並計算異常過濾器表示式的值，過濾器表示式的結果值只能是下面三個識別符號之一，這些識別符號定義在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. Traner 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塊之後的第一條指令恢復。

在現在，軟體變的越來越大，如果不用SEH，要實現完全強壯的應用程式簡直是不可能的。我們先來看一個樣板程式，即C的執行時函式strcpy：這是一個相當簡單的函式，它怎麼會引起一個程式結束呢？如果呼叫者對這些引數中的某一個傳遞NULL（或任何無效的地址），strcpy就引起一個存取異常，並且導致整個程式結束。使用SEH，就可以建立一個完全強壯的strcpy函式：
char* RobustStrcpy(char* strDes, char* strSource)
{
__try
{
strcpy(strDes, strSource);
}
__except(EXCEPTION_EXECUTE_HANDLER)
{
do no thing
}
return strDes;
}
這個函式所做的一切就是將對strcpy的呼叫置於一個結構化的異常處理中。如果strcpy執行成功，函式就返回。如果strcpy引起一個存取異常，導致該執行緒執行異常處理程式程式碼。在這個函式中，處理程式程式碼什麼也不做，RobustStrcpy只是返回到它的呼叫者，根本不會造成程式結束。

下面這段程式碼中的函式，返回一個字串裡的以空格分界的符號個數：
DWORD Func_RobustTokens(const char* str)
{
DWORD iTokens = -1;
char* strTemp = NULL;
__try
{
strTemp = (char*)malloc(strlen(str)+1);
strcpy(strTemp, str);
char* pszToken = strtok(strTemp, " ");
for(; pszToken!=NULL; pszToken = strtok(NULL," "))
iTokens++;
iTokens++;
}
__except(EXCEPTION_EXECUTE_HANDLER)
{
nothing for test
}
free(strTemp);
return iTokens;
}
看看在幾個不同的情況下這個函式能任何做：
首先，如果呼叫者向函式傳遞了NULL（或任何無效的記憶體地址），iTokens被初始化成-1。在try塊中對strlen的呼叫會引起存取異常。異常過濾器獲得控制並將控制轉移給except塊，except塊什麼也不做。在except塊之後，呼叫free來釋放臨時記憶體塊。但是，這個記憶體從未分配，所以結束呼叫free，向它傳遞NULL作為引數。ANSI C明確說明用NULL作為引數呼叫free是合法的。這時free什麼也不做，這並不是錯誤。最後，函式返回-1，指出失敗。注意程式並沒有結束。
其次，呼叫者可能向函式傳遞了一個有效的地址，但對malloc的呼叫（在try塊中）可能失敗並返回NULL。這將導致對strcpy的呼叫引起一個存取異常。同樣，異常過濾器被呼叫，except塊執行（什麼也不做），free被呼叫，傳遞給它NULL（什麼也不做），返回-1，告訴呼叫程式該函式失敗。注意程式也沒有結束。
最後，假定呼叫者向函式傳遞了一個有效的地址，並且對malloc的呼叫也成功了。這種情
況下，其餘的程式碼也會成功地在iTokens變數中計算符號的數量。在try塊的結尾，異常過濾器不會被求值， except塊中程式碼不會被執行，臨時記憶體緩衝區將被釋放，並向呼叫者返
回iTokens。
使用SEH會感覺很好。

前面的幾個程式碼在__except中都沒有程式碼，現在我們來看這段程式碼：
PBYTE Func_RobustMemDup(PBYTE pbSrc, size_t cb)
{
PBYTE pbDup = NULL;
__try
{
pbDup = (PBYTE)malloc(cb);
memcpy(pbDup, pbSrc, cb);
}
__except(EXCEPTION_EXECUTE_HANDLER)
{
free(pbDup);
pbDup = NULL;
}
return pbDup;
}
這個函式分配一個記憶體緩衝區，並從源塊向目的塊複製位元組。然後函式將複製的記憶體緩衝區
的地址返回給呼叫程式（如果函式失敗則返回NULL）。希望呼叫程式在不需要緩衝區時釋放它。
這是在except塊中實際有程式碼的第一個例子。我們看一看這個函式在不同條件下是如何執行的。
• 如果呼叫程式對pbSrc引數傳遞了一個無效地址，或者如果對malloc的呼叫失敗（返回NULL），memcpy將引起一個存取異常。該存取異常執行過濾器，將控制轉移到except塊。在except塊內，記憶體緩衝區被釋放， pbDup被設定成NULL以便呼叫程式能夠知道函式失敗。這裡，注意ANSI C允許對free傳遞NULL。
• 如果呼叫程式給函式傳遞一個有效地址，並且如果對malloc的呼叫成功，則新分配記憶體
塊的地址返回給呼叫程式

全域性展開
當一個異常過濾器的值為EXCEPTION_EXECUTE_HANDLER時，系統必須執行一個全域性展開（global unwind）。這個全域性展開使所有那些在處理異常的try _ except塊之後開始執行但未完成的try_finally塊恢復執行。
關於全域性展開在這裡不在繼續介紹了（寫這篇文擋已經是第4天了，我倒~），全域性展開也就是在try _ except的try中呼叫了含有try_finally的程式碼或函式。

另，透過在finally塊中放入一個return語句，就可以阻止系統去完成一個全域性展開。雖然MS透過這種設計，來讓程式設計師把展開停止，讓程式碼繼續下去，但我曾經說過，儘量的避免在finally塊中放入return 語句。

EXCEPTION_CONTINUE_EXECUTION
我們再仔細考察一下異常過濾器，看它是如何計算出定義在Excpt.h中的三個異常識別符號之一的。在前面的程式碼中，我們直接對異常的過濾器設定值為EXCEPTION_EXECUTE_HANDLER，但實際上我們應該讓根據具體的情況來得到過濾器的值，比如呼叫一個函式確定應該返回哪一個識別符號。

發生一個異常，如果是EXCEPTION_CONTINUE_EXECUTION標誌，程式碼會試圖對發生異常的程式碼再執行一遍（這個時候__except塊中的程式碼並沒有被執行！），所以我們使用EXCEPTION_CONTINUE_EXECUTION的時候，一般都會在返回EXCEPTION_CONTINUE_EXECUTION過濾標誌之前，把我們的錯誤程式碼修改回來，否則會進入到死迴圈中。下面這段程式碼就會導致死迴圈：
DWORD Func_SEHExceptionContinue()
{
DWORD dwTemp = 0;
__try {
dwTemp = 5/dwTemp;
dwTemp += 10;
}
__except(EXCEPTION_CONTINUE_EXECUTION) {
MessageBeep(0);
}
return dwTemp;
}
在使用EXCEPTION_CONTINUE_EXECUTION的時候，一定要特別的小心，有一種情況可以保證每次使用EXCEPTION_CONTINUE_EXECUTION都能成功：
當離散地向一個保留區域提交儲存區時。

將虛擬記憶體技術同結構化異常處理結合起來，可以編寫一些執行非常快，非常高效的程式。

EXCEPTION_CONTINUE_SEARCH
EXCEPTION_CONTINUE_SEARCH：是告訴系統繼續上溯呼叫樹，去尋找另外的異常過濾器。（如果每個過濾器都返回EXCEPTION_CONTINUE_SEARCH時會出現什麼情況呢？在這種情況下，就出現了所謂的“未處理異常”（Unhandled exception））

大家把下面這段程式碼跟蹤一遍就明白了：
void Func_SEHPost(char* sz)
{
__try{
*sz = 0;
}
__except(EXCEPTION_CONTINUE_SEARCH) {
never Exceute
cout< }
}

DWORD GetExceptionFliterCode(char** ppszBuffer)
{
if(*ppszBuffer == NULL)
{
*ppszBuffer = g_szBuffer;
return EXCEPTION_CONTINUE_EXECUTION;
}
return EXCEPTION_EXECUTE_HANDLER;
}

DWORD Func_SEHExceptionSearch()
{
char* pszBuffer = NULL;
__try{
Func_SEHPost(pszBuffer);
}
__except(GetExceptionFliterCode(&pszBuffer))
{
cout< }
return TRUE;
}

GetExceptionCode
一個異常過濾器在確定要返回什麼值之前，必須分析具體情況。例如，異常處理程式可能知道發生了除以0引起的異常時該怎麼做，但是不知道該如何處理一個記憶體存取異常。異常過濾器負責檢查實際情況並返回適當的值。
下面的程式碼舉例說明了一種方法，指出所發生異常的類別：
BOOL Func_SEHExceptionGetCodeBase()
{
int x,y;
__try{
x = 0;
y = 4/x;
}
__except((GetExceptionCode() == EXCEPTION_INT_DIV_BY_ZERO) ?
EXCEPTION_EXECUTE_HANDLER :
EXCEPTION_CONTINUE_SEARCH)
{
divide by zero exception
}
}
GetExceptionCode返回一個值，該值指出所發生異常的種類：
下面列出所有預定義的異常和相應的含意，這些內容取自PlatfoSDK文件。這些異常識別符號可以在WinBase.h檔案中找到。我們對這些異常做了分類。
1. 與記憶體有關的異常
• E X C E P T I O N _ A C C E S S _ V I O L AT I O N。執行緒試圖對一個虛地址進行讀或寫，但沒有做適當的存取。這是最常見的異常。
• E X C E P T I O N _ D ATAT Y P E _ M I S A L I G N M E N T。執行緒試圖讀或寫不支援對齊（ a l i g n m e n t）的硬體上的未對齊的資料。例如， 1 6位數值必須對齊在2位元組邊界上，3 2

異常處理 (轉)

相關文章