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列子的構想都來自他的指導；另外要感謝SCOtt Meyers大師，我是看他的書長大的；還要感謝Adamc / Darwin / Julian ，當然還有Nick的Coffee
內容導讀：
（請打開文檔結構圖來讀這篇文章。）
本文包括2個大的異常實現概念：C++的標準異常和SHE異常。
C++標準異常：也許我們瞭解過他，但你有考慮過，其實你根本不會使用，你不相信，那我問你：垃圾回收在C++中怎麼實現？其實不需要實現，C++ 已經有了，但是你不會用，那麼從<構造和析構中的異常拋出>開始看把。也許很高興看到錯誤之後的Heap/Stack中對象被釋放，可是如果沒有呢？有或者試想一下一個能解決的錯誤，需要我們把整個程序Kill掉嗎？
在C++標準異常中我向你推薦這幾章：<使用異常規格編程> <構造和析構中的異常拋出> <使用析構函數防止資源泄漏> 以及一個深點的<拋出一個異常的行爲>
SHE異常： 我要問你你是一個win32程序員嗎？如果不是，那麼也許你真的不需要看
這塊內容了，SHE是windows的結構化異常，每一個WIN32程序員都應該要掌握它。SHE功能強大，包括TeRmination 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，但 這是有解決的方法的，那就是使用“靈巧指針”。
如果對照<More effective C++>的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/Resource Leak變的更有可能了（別說什麼Memory便宜了，那不是一個優秀的程序員說的話。），寫出一個具有你希望的行爲的構造函數和析構函數也變的困難（不可預測），當然最危險的也許是我們寫出的東東狗屁了，或者是速度變慢了。
大多數的程序員知道Howto use exception 來處理我們的代碼，可是很多人並不是很重視異常的處理（國外的很多Code倒是處理的很好，Java的Exception機制很不錯）。異常處理機制是解決某些問題的上佳辦法，但同時它也引入了許多隱藏的控制流程；有時候，要正確無誤的使用它並不容易。
在異常被throw後，沒有一個方法能夠做到使軟件的行爲具有可預測性和可靠性（這句話不是我說的，是Jack Reeves寫的Coping 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 <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); file://得到下一個動物
pa->processAdoption(); file://處理收容動物
delete pa; file://刪除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將被丟 失，就象其它動態分配的資源一樣。
解決方法與前面所述的一樣，建立一個類，讓它的構造函數與析構函數來獲取和釋放資源：
file://一個類，獲取和釋放一個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拷貝
file://有關一個更靈活的方法的討論請參見下面的靈巧指針
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 { ... }; file://一個類，具體是什麼類
// 在這裏並不重要
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) ... file://一些catch 子句，用來
catch (Widget& w) ... file://捕獲異常，異常的類型爲
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; file://傳遞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）;
file://一直存在至程序結束
cin >> localWidget; // 象以前那樣運行
throw localWidget; // 仍將對localWidget
} file://進行拷貝操作
當 拋出異常時仍將複製出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; file://它拋出一個類型爲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) ... file://通過傳遞指向const的引用
file://捕獲異常
我 們立刻注意到了傳遞參數與傳遞異常的另一個差異。一個被異常拋出的對象（剛纔解釋過，總是一個臨時對象）可以通過普通的引用捕獲；它不需要通過指向 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; file://真，拋出一個整形值
...
}
}
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*) ... file://捕獲任何指針類型異常
傳遞參數和傳遞異常間最後一點差別是catch子句匹配順序總是取決於它們在程序中出現的順序。因此一個派生類異常可能被處理其基類異常的catch子句捕獲，即使同時存在有能處理該派生類異常的catch子句，與相同的try塊相對應。例如：
try {
...
}
catch (logic_error& ex) { // 這個catch塊 將捕獲
... // 所有的logic_error
} // 異常, 包括它的派生類
catch (invalid_argument& ex) { // 這個塊永遠不會被執行
... file://因爲所有的
} // invalid_argument
// 異常 都被上面的
// catch子句捕獲。
與 上面這種行爲相反，當你調用一個虛擬函數時，被調用的函數位於與發出函數調用的對象的動態類型（dynamic type）最相近的類裏。你可以這樣說虛擬函數採用最優適合法，而異常處理採用的是最先適合法。如果一個處理派生類異常的catch子句位於處理基類異常 的catch子句前面，編譯器會發出警告。（因爲這樣的代碼在C++裏通常是不合法的。）不過你最好做好預先防範：不要把處理基類異常的catch子句放 在處理派生類異常的catch子句的前面。象上面那個例子，應該這樣去寫：
try {
...
}
catch (invalid_argument& ex) { // 處理 invalid_argument
... file://異常
}
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 + +的異常處理，並且在內部實現上利用了已經引入到編譯程序和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
{
file://保護塊
}
__finally
{
file://結束處理程序
}
在 上面的代碼段中，操作系統和編譯程序共同來確保結束處理程序中的__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，性能消耗：小）
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;
}
在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 cpu上使用微軟的編譯程序，當執行離開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'; // <- Here, Will Happen a Access Exception!
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
{
file://保護塊
}
__except(異常過慮器)
{
file://異常處理程序
}
注 意__ 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. 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塊之後的第一條指令恢復。
在現在，軟件變的越來越大，如果不用SEH，要實現完全強壯的應用程序簡直是不可能的。我們先來看一個樣板程序，即C的運行時函數 strcpy：這是一個相當簡單的函數，它怎麼會引起一個進程結束呢？如果調用者對這些參數中的某一個傳遞NULL（或任何無效的地址），strcpy就 引起一個存取異常，並且導致整個進程結束。使用SEH，就可以建立一個完全強壯的strcpy函數：
char* RobustStrcpy(char* strDes, char* strSource)
{
__try
{
strcpy(strDes, strSource);
}
__except(EXCEPTION_EXECUTE_HANDLER)
{
file://don't 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)
{
file://Do 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) {
file://Here never Exceute
cout<<"If have message, Here is Error"<<endl;
}
}
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<<"Exception Block Run"<<endl;
}
return TRUE;
}
GetExceptionCode
一個異常過濾器在確定要返回什麼值之前，必須分析具體情況。例如，異常處理程序可能知道發生了除以0引起的異常時該怎麼做，但是不知道該如何處理一個內存存取異常。異常過濾器負責檢查實際情況並返回適當的值。
下面的代碼舉例說明了一種方法，指出所發生異常的類別：
BOOL Func_SEHExceptionGetCodeBase()
{
int x,y;
__try{
x = 0;
y = 4/x;
}
__except((GetExceptionCode() == EXCEPTION_INT_DIVide_BY_ZERO) ?
EXCEPTION_EXECUTE_HANDLER :
EXCEPTION_CONTINUE_SEARCH)
{
file://handle divide by zero exception
}
}
GetExceptionCode返回一個值，該值指出所發生異常的種類：
下面列出所有預定義的異常和相應的含意，這些內容取自PlatfoRM SDK文檔。這些異常標識符可以在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�