寫在前面

　　所謂異常處理，即讓一個程序運行時遇到自己無法處理的錯誤時拋出一個異常，希望調(diào)用者可以發(fā)現(xiàn)處理問題.

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

　　也許我們已經(jīng)使用過異常，但是你習(xí)慣使用異常了嗎？

　　現(xiàn)在很多軟件都是n*365*24小時運行，軟件的健壯性至關(guān)重要.

內(nèi)容導(dǎo)讀

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

　　C++標準異常：

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

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

　　 在《C++標準異?！分形蚁蚰阃扑]這幾章：

　　 <使用異常規(guī)格編程> <構(gòu)造和析構(gòu)中的異常拋出> <使用析構(gòu)函數(shù)防止資源泄漏>,以及深入一點的<拋出一個異常的行為>.

　　SEH異常：

　　　　我要問你你是一個WIN32程序員嗎？如果不是，那么也許你真的不需要看.

　　　　SEH是Windows的結(jié)構(gòu)化異常，每一個WIN32程序員都應(yīng)該要掌握它.

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

　　　　強有力的維護了代碼的健壯，雖然要以部分系統(tǒng)性能做犧牲(其實可以避免).

　　　　在SEH中有大量的代碼，已經(jīng)在Win平臺上測試過了.

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

　　　　對__finally來說當(dāng)遇到ExitThread/ExitProcess/abort等函數(shù)時，finally塊不會被執(zhí)行.

另:<使用析構(gòu)函數(shù)防止資源泄漏>這個節(jié)點引用了More effective C++的條款9.

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

如果對照<More effective C++>的37條條款，關(guān)于異常的高級使用，有以下內(nèi)容是沒有完成的：

1. 使用構(gòu)造函數(shù)防止資源Leak（More effective C++ #10）

2. 禁止異常信息傳遞到析構(gòu)Function外 (More effective C++ #11)

3. 通過引用捕獲異常 （More effective C++ #13）

4. 謹慎使用異常規(guī)格 （More effective C++ #14）

5. 了解異常處理造成的系統(tǒng)開銷 （More effective C++ #15）

6. 限制對象數(shù)量 （More effective C++ #26）

7. 靈巧指針 （More effective C++ #28）

C++異常 C++引入異常的原因

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

寫出一個具有你希望的行為的構(gòu)造函數(shù)和析構(gòu)函數(shù)也變的困難（不可預(yù)測），當(dāng)然最危險的也許是我們寫出的東東狗屁了，或者是速度變慢了.

大多數(shù)的程序員知道Howto use exception 來處理我們的代碼，可是很多人并不是很重視異常的處理（國外的很多Code倒是處理的很好，Java的Exception機制很不錯）.

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

在異常被throw后，沒有一個方法能夠做到使軟件的行為具有可預(yù)測性和可靠性

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

如果一個函數(shù)通過設(shè)置一個狀態(tài)變量或返回錯誤代碼來表示一個異常狀態(tài)，沒有辦法保證函數(shù)調(diào)用者將一定檢測變量或測試錯誤代碼.

結(jié)果程序會從它遇到的異常狀態(tài)繼續(xù)運行，異常沒有被捕獲，程序立即會終止執(zhí)行.

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

這2個函數(shù)來完成和異常處理相識的功能，但是MSDN中介紹了在C++中使用longjmp來調(diào)整stack時不能夠?qū)植康膶ο笳{(diào)用析構(gòu)函數(shù)，

但是對C++程序來說，析構(gòu)函數(shù)是重要的（我就一般都把對象的Delete放在析構(gòu)函數(shù)中）.

所以我們需要一個方法：

　　①能夠通知異常狀態(tài)，又不能忽略這個通知.

　?、诓⑶襍earching the stack以便找到異常代碼時.

　?、圻€要確保局部對象的析構(gòu)函數(shù)被Call.

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

有的地方只有用異常才能解決問題，比如說，在當(dāng)前上下文環(huán)境中，無法捕捉或確定的錯誤類型，我們就得用一個異常拋出到更大的上下文環(huán)境當(dāng)中去.

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

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

C++使用throw關(guān)鍵字來產(chǎn)生異常，try關(guān)鍵字用來檢測的程序塊，catch關(guān)鍵字用來填寫異常處理的代碼.

異?？梢杂梢粋€確定類或派生類的對象產(chǎn)生。C++能釋放堆棧，并可清除堆棧中所有的對象.

C++的異常和pascal不同，是要程序員自己去實現(xiàn)的，編譯器不會做過多的動作.

throw異常類編程,拋出異常用throw， 如：

throw ExceptionClass(“my throw“);

例句中，ExceptionClass是一個類，它的構(gòu)造函數(shù)以一個字符串做為參數(shù).

也就是說，在throw的時候，C++的編譯器先構(gòu)造一個ExceptionClass的對象，讓它作為throw的值拋出去,同時，程序返回，調(diào)用析構(gòu).

看下面這個程序：

#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 （這里是異常處理空間中對異常類的拷貝的析構(gòu)）
Destruct Test
======================================

不過一般來說我們可能更習(xí)慣于把會產(chǎn)生異常的語句和要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

 使用異常規(guī)格編程

如果我們調(diào)用別人的函數(shù)，里面有異常拋出，用去查看它的源代碼去看看都有什么異常拋出嗎？這樣就會很煩瑣.
比較好的解決辦法，是編寫帶有異常拋出的函數(shù)時，采用異常規(guī)格說明，使我們看到函數(shù)聲明就知道有哪些異常出現(xiàn)。
異常規(guī)格說明大體上為以下格式：

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

所有異常類都在函數(shù)末尾的throw()的括號中得以說明了，這樣，對于函數(shù)調(diào)用者來說，是一清二楚的。
注意下面一種形式：

void ExceptionFunction(argument…) throw()

表明沒有任何異常拋出.

而正常的void ExceptionFunction(argument…)則表示：可能拋出任何一種異常，當(dāng)然，也可能沒有異常，意義是最廣泛的.
異常捕獲之后，可以再次拋出，就用一個不帶任何參數(shù)的throw語句就可以了.
構(gòu)造和析構(gòu)中的異常拋出

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

先看個程序，假如我在構(gòu)造函數(shù)的地方拋出異常，這個類的析構(gòu)會被調(diào)用嗎？可如果不調(diào)用，那類里的東西豈不是不能被釋放了？

#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(...)
   {}
}

結(jié)果為：

ExceptionClass1()
throw a exception

在這兩句輸出之間，我們已經(jīng)給S分配了內(nèi)存，但內(nèi)存沒有被釋放（因為它是在析構(gòu)函數(shù)中釋放的）.
應(yīng)該說這符合實際現(xiàn)象，因為對象沒有完整構(gòu)造.
為了避免這種情況，我想你也許會說：應(yīng)避免對象通過本身的構(gòu)造函數(shù)涉及到異常拋出.
即：既不在構(gòu)造函數(shù)中出現(xiàn)異常拋出，也不應(yīng)在構(gòu)造函數(shù)調(diào)用的一切東西中出現(xiàn)異常拋出.
但是在C++中可以在構(gòu)造函數(shù)中拋出異常，經(jīng)典的解決方案是使用STL的標準類auto_ptr.
其實我們也可以這樣做來實現(xiàn)：
　　在類中增加一個 Init()以及 UnInit();成員函數(shù)用于進行容易產(chǎn)生錯誤的資源分配工作，而真正的構(gòu)造函數(shù)中先將所有成員置為NULL，然后調(diào)用 Init();
并判斷其返回值/或者捕捉 Init()拋出的異常，如果Init();失敗了，則在構(gòu)造函數(shù)中調(diào)用 UnInit(); 并設(shè)置一個標志位表明構(gòu)造失敗.
UnInit()中按照成員是否為NULL進行資源的釋放工作.
那么，在析構(gòu)函數(shù)中的情況呢？
我們已經(jīng)知道，異常拋出之后，就要調(diào)用本身的析構(gòu)函數(shù)，如果這析構(gòu)函數(shù)中還有異常拋出的話，則已存在的異常尚未被捕獲，會導(dǎo)致異常捕捉不到.

標準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 報告程序的邏輯錯誤，可在程序執(zhí)行前被檢測到.

runtime_erro 報告程序運行時的錯誤，只有在運行的時候才能檢測到.

以上兩個又分別有自己的派生類：
③ 由logic_erro派生的異常類

domain_error           報告違反了前置條件
invalid_argument       指出函數(shù)的一個無效參數(shù)
length_error 　　　　　　指出有一個產(chǎn)生超過NPOS長度的對象的企圖（NPOS為size_t的最大可表現(xiàn)值
out_of_range 　　　　　　報告參數(shù)越界
bad_cast               在運行時類型識別中有一個無效的dynamic_cast表達式
bad_typeid 　　　　　　　報告在表達式typeid(*p)中有一個空指針P

④ 由runtime_error派生的異常

range_error　　　　 報告違反了后置條件
overflow_error 　　報告一個算術(shù)溢出
bad_alloc 報告一個存儲分配錯誤

使用析構(gòu)函數(shù)防止資源泄漏

這部分是一個經(jīng)典和很平常就會遇到的實際情況，下面的內(nèi)容大部分都是從More Effective C++條款中得到的.
假設(shè)，你正在為一個小動物收容所編寫軟件，小動物收容所是一個幫助小狗小貓尋找主人的組織.

每天收容所建立一個文件，包含當(dāng)天它所管理的收容動物的資料信息，你的工作是寫一個程序讀出這些文件然后對每個收容動物進行適當(dāng)?shù)奶幚恚╝ppropriate processing）.

完成這個程序一個合理的方法是定義一個抽象類，ALA（"Adorable Little Animal")，然后為小狗和小貓建立派生類.
一個虛擬函數(shù)processAdoption分別對各個種類的動物進行處理：

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

你需要一個函數(shù)從文件中讀信息，然后根據(jù)文件中的信息產(chǎn)生一個puppy（小狗）對象或者kitten(小貓)對象.
這個工作非常適合于虛擬構(gòu)造器（virtual constructor），在條款25詳細描述了這種函數(shù).
為了完成我們的目標，我們這樣聲明函數(shù)：

// 從s中讀動物信息, 然后返回一個指針
// 指向新建立的某種類型對象
ALA * readALA(istream& s);

你的程序的關(guān)鍵部分就是這個函數(shù)，如下所示：

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

這個函數(shù)循環(huán)遍歷dataSource內(nèi)的信息，處理它所遇到的每個項目.
唯一要記住的一點是在每次循環(huán)結(jié)尾處刪除ps.
這是必須的，因為每次調(diào)用readALA都建立一個堆對象.如果不刪除對象，循環(huán)將產(chǎn)生資源泄漏。
現(xiàn)在考慮一下，如果pa->processAdoption拋出了一個異常，將會發(fā)生什么？
processAdoptions沒有捕獲異常，所以異常將傳遞給processAdoptions的調(diào)用者.
轉(zhuǎn)遞中，processAdoptions函數(shù)中的調(diào)用pa->processAdoption語句后的所有語句都被跳過，這就是說pa沒有被刪除.
結(jié)果，任何時候pa->processAdoption拋出一個異常都會導(dǎo)致processAdoptions內(nèi)存泄漏.
很容易堵塞泄漏.

void processAdoptions(istream& dataSource)
{
   while(dataSource)
   {
      ALA *pa = readALA(dataSource);
      try
      {
         pa->processAdoption();
      }
      catch(...)
      {
         　　　　　　　// 捕獲所有異常
         delete pa; 　　　　　　　 // 避免內(nèi)存泄漏
         　　　　　　　　　　　　　　 // 當(dāng)異常拋出時
         throw; 　　　　　　　　　 // 傳送異常給調(diào)用者
      }
      delete pa; 　　　　　　　　 // 避免資源泄漏
   }　　　　　　　　　　　　　 // 當(dāng)沒有異常拋出時
}

但是你必須用try和catch對你的代碼進行小改動.
更重要的是你必須寫雙份清除代碼，一個為正常的運行準備，一個為異常發(fā)生時準備.
在這種情況下，必須寫兩個delete代碼.
象其它重復(fù)代碼一樣，這種代碼寫起來令人心煩又難于維護，而且它看上去好像存在著問題.
不論我們是讓processAdoptions正常返回還是拋出異常，我們都需要刪除pa，所以為什么我們必須要在多個地方編寫刪除代碼呢？
我們可以把總被執(zhí)行的清除代碼放入processAdoptions函數(shù)內(nèi)的局部對象的析構(gòu)函數(shù)里，這樣可以避免重復(fù)書寫清除代碼.
因為當(dāng)函數(shù)返回時局部對象總是被釋放，無論函數(shù)是如何退出的.
（僅有一種例外就是當(dāng)你調(diào)用longjmp時。Longjmp的這個缺點是C++率先支持異常處理的主要原因）
具體方法是用一個對象代替指針pa，這個對象的行為與指針相似。當(dāng)pointer-like（類指針）對象被釋放時，我們能讓它的析構(gòu)函數(shù)調(diào)用delete.
替代指針的對象被稱為smart pointers（靈巧指針），下面有解釋，你能使得pointer-like對象非常靈巧.
在這里，我們用不著這么聰明的指針，我們只需要一個pointer-lik對象，當(dāng)它離開生存空間時知道刪除它指向的對象.
寫出這樣一個類并不困難，但是我們不需要自己去寫。標準C++庫函數(shù)包含一個類模板，叫做auto_ptr，這正是我們想要的.
每一個auto_ptr類的構(gòu)造函數(shù)里，讓一個指針指向一個堆對象（heap object），并且在它的析構(gòu)函數(shù)里刪除這個對象.

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

template<class T>
class auto_ptr
{
public:
   　auto_ptr(T *p = 0): ptr(p) {}　　　　// 保存ptr，指向?qū)ο?
   　~auto_ptr() { delete ptr; }　　　　　// 刪除ptr指向的對象
private:
   　T *ptr;     　 // raw ptr to object
};

auto_ptr類的完整代碼是非常有趣的，上述簡化的代碼實現(xiàn)不能在實際中應(yīng)用.
（我們至少必須加上拷貝構(gòu)造函數(shù)，賦值operator以及下面將要講到的pointer-emulating函數(shù)）
但是它背后所蘊含的原理應(yīng)該是清楚的：用auto_ptr對象代替raw指針，你將不再為堆對象不能被刪除而擔(dān)心，即使在拋出異常時，對象也能被及時刪除.
(因為auto_ptr的析構(gòu)函數(shù)使用的是單對象形式的delete，所以auto_ptr不能用于指向?qū)ο髷?shù)組的指針.
如果想讓auto_ptr類似于一個數(shù)組模板，你必須自己寫一個。在這種情況下，用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在兩個方面區(qū)別于原來的processAdoptions函數(shù).
第一， pa被聲明為一個auto_ptr<ALA>對象，而不是一個raw ALA*指針.
第二， 在循環(huán)的結(jié)尾沒有delete語句.
其余部分都一樣，因為除了析構(gòu)的方式，auto_ptr對象的行為就象一個普通的指針。是不是很容易.
隱藏在auto_ptr后的思想是：
　　用一個對象存儲需要被自動釋放的資源，然后依靠對象的析構(gòu)函數(shù)來釋放資源，這種思想不只是可以運用在指針上，還能用在其它資源的分配和釋放上.
想一下這樣一個在GUI程序中的函數(shù)，它需要建立一個window來顯式一些信息：
// 這個函數(shù)會發(fā)生資源泄漏，如果一個異常拋出

void displayInfo(const Information& info)
{
   　WINDOW_HANDLE w(createWindow());//在w對應(yīng)的window中顯式信息
   　destroyWindow(w);
   
}

很多window系統(tǒng)有C－like接口，使用象like createWindow 和 destroyWindow函數(shù)來獲取和釋放window資源.
如果在w對應(yīng)的window中顯示信息時，一個異常被拋出，w所對應(yīng)的window將被丟失，就象其它動態(tài)分配的資源一樣.
解決方法與前面所述的一樣，建立一個類，讓它的構(gòu)造函數(shù)與析構(gòu)函數(shù)來獲取和釋放資源：

//一個類，獲取和釋放一個window 句柄
class WindowHandle
{
public:
   　 WindowHandle(WINDOW_HANDLE handle): w(handle) {}
   　~WindowHandle() { destroyWindow(w); }
   　 operator WINDOW_HANDLE() { return w; }　　　　// see below
private:
   　WINDOW_HANDLE w;
   　// 下面的函數(shù)被聲明為私有，防止建立多個WINDOW_HANDLE拷貝
   //有關(guān)一個更靈活的方法的討論請參見下面的靈巧指針
   　WindowHandle(const WindowHandle&);
   　WindowHandle& operator=(const WindowHandle&);
};

這看上去有些象auto_ptr，只是賦值操作與拷貝構(gòu)造被顯式地禁止（參見More effective C++條款27），有一個隱含的轉(zhuǎn)換操作能把WindowHandle轉(zhuǎn)換為WINDOW_HANDLE.
這個能力對于使用WindowHandle對象非常重要，因為這意味著你能在任何地方象使用raw WINDOW_HANDLE一樣來使用WindowHandle.
（參見More effective C++條款5 ，了解為什么你應(yīng)該謹慎使用隱式類型轉(zhuǎn)換操作）
通過給出的WindowHandle類，我們能夠重寫displayInfo函數(shù)，如下所示：

// 如果一個異常被拋出，這個函數(shù)能避免資源泄漏
void displayInfo(const Information& info)
{
   WindowHandle w(createWindow());
   //在w對應(yīng)的window中顯式信息;
}

即使一個異常在displayInfo內(nèi)被拋出，被createWindow 建立的window也能被釋放.
資源應(yīng)該被封裝在一個對象里，遵循這個規(guī)則，你通常就能避免在存在異常環(huán)境里發(fā)生資源泄漏.
但是如果你正在分配資源時一個異常被拋出，會發(fā)生什么情況呢？
例如當(dāng)你正處于resource-acquiring類的構(gòu)造函數(shù)中.
還有如果這樣的資源正在被釋放時，一個異常被拋出，又會發(fā)生什么情況呢？
構(gòu)造函數(shù)和析構(gòu)函數(shù)需要特殊的技術(shù).
你能在More effective C++條款10和More effective C++條款11中獲取有關(guān)的知識.
拋出一個異常的行為
個人認為接下來的這部分其實說的很經(jīng)典，對我們理解異常行為/異?？截愂呛苡袔椭?
條款12：理解“拋出一個異常”與“傳遞一個參數(shù)”或“調(diào)用一個虛函數(shù)”間的差異
從語法上看，在函數(shù)里聲明參數(shù)與在catch子句中聲明參數(shù)幾乎沒有什么差別：

class Widget { ... }; //一個類，具體是什么類在這里并不重要
void f1(Widget w); // 一些函數(shù)，其參數(shù)分別為
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子句中與通過函數(shù)調(diào)用傳遞一個參數(shù)兩者基本相同.
這里面確有一些相同點，但是他們也存在著巨大的差異.
讓我們先從相同點談起.
你傳遞函數(shù)參數(shù)與異常的途徑可以是傳值、傳遞引用或傳遞指針，這是相同的.
但是當(dāng)你傳遞參數(shù)和異常時，系統(tǒng)所要完成的操作過程則是完全不同的.
產(chǎn)生這個差異的原因是：你調(diào)用函數(shù)時，程序的控制權(quán)最終還會返回到函數(shù)的調(diào)用處，但是當(dāng)你拋出一個異常時，控制權(quán)永遠不會回到拋出異常的地方。
有這樣一個函數(shù)，參數(shù)類型是Widget，并拋出一個Widget類型的異常：

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

當(dāng)傳遞localWidget到函數(shù)operator>>里，不用進行拷貝操作，而是把operator>>內(nèi)的引用類型變量w指向localWidget，任何對w的操作實際上都施加到localWidget上.
這與拋出localWidget異常有很大不同.
不論通過傳值捕獲異常還是通過引用捕獲（不能通過指針捕獲這個異常，因為類型不匹配）都將進行l(wèi)calWidget的拷貝操作，也就說傳遞到catch子句中的是localWidget的拷貝.
必須這么做，因為當(dāng)localWidget離開了生存空間后，其析構(gòu)函數(shù)將被調(diào)用.
如果把localWidget本身（而不是它的拷貝）傳遞給catch子句，這個子句接收到的只是一個被析構(gòu)了的Widget，一個Widget的“尸體”.
這是無法使用的。因此C++規(guī)范要求被做為異常拋出的對象必須被復(fù)制.
即使被拋出的對象不會被釋放，也會進行拷貝操作.
例如如果passAndThrowWidget函數(shù)聲明localWidget為靜態(tài)變量（static），

void passAndThrowWidget()
{
   static Widget localWidget;    // 現(xiàn)在是靜態(tài)變量（static） 一直存在至程序結(jié)束
   cin >> localWidget;        // 象以前那樣運行
   throw localWidget;        // 仍將對localWidget進行拷貝操作
}

當(dāng)拋出異常時仍將復(fù)制出localWidget的一個拷貝.
這表示即使通過引用來捕獲異常，也不能在catch塊中修改localWidget;僅僅能修改localWidget的拷貝.
對異常對象進行強制復(fù)制拷貝，這個限制有助于我們理解參數(shù)傳遞與拋出異常的第二個差異：拋出異常運行速度比參數(shù)傳遞要慢.
當(dāng)異常對象被拷貝時，拷貝操作是由對象的拷貝構(gòu)造函數(shù)完成的.
該拷貝構(gòu)造函數(shù)是對象的靜態(tài)類型（static type）所對應(yīng)類的拷貝構(gòu)造函數(shù)，而不是對象的動態(tài)類型（dynamic type）對應(yīng)類的拷貝構(gòu)造函數(shù).
比如以下這經(jīng)過少許修改的passAndThrowWidget：

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

這里拋出的異常對象是Widget，即使rw引用的是一個SpecialWidget.
因為rw的靜態(tài)類型（static type）是Widget，而不是SpecialWidget.
你的編譯器根本沒有主要到rw引用的是一個SpecialWidget。編譯器所注意的是rw的靜態(tài)類型（static type）.
這種行為可能與你所期待的不一樣，但是這與在其他情況下C++中拷貝構(gòu)造函數(shù)的行為是一致的.
（不過有一種技術(shù)可以讓你根據(jù)對象的動態(tài)類型dynamic type進行拷貝，參見條款25）
異常是其它對象的拷貝，這個事實影響到你如何在catch塊中再拋出一個異常.
比如下面這兩個catch塊，乍一看好像一樣：

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

這兩個catch塊的差別在于第一個catch塊中重新拋出的是當(dāng)前捕獲的異常，而第二個catch塊中重新拋出的是當(dāng)前捕獲異常的一個新的拷貝.
如果忽略生成額外拷貝的系統(tǒng)開銷，這兩種方法還有差異么？
當(dāng)然有。第一個塊中重新拋出的是當(dāng)前異常（current exception）,無論它是什么類型.
特別是如果這個異常開始就是做為SpecialWidget類型拋出的，那么第一個塊中傳遞出去的還是SpecialWidget異常，即使w的靜態(tài)類型（static type）是Widget.
這是因為重新拋出異常時沒有進行拷貝操作.
第二個catch塊重新拋出的是新異常，類型總是Widget，因為w的靜態(tài)類型（static type）是Widget.
一般來說，你應(yīng)該用throw來重新拋出當(dāng)前的異常，因為這樣不會改變被傳遞出去的異常類型，而且更有效率，因為不用生成一個新拷貝.
（順便說一句，異常生成的拷貝是一個臨時對象.
正如條款19解釋的，臨時對象能讓編譯器優(yōu)化它的生存期（optimize it out of existence），
不過我想你的編譯器很難這么做，因為程序中很少發(fā)生異常，所以編譯器廠商不會在這方面花大量的精力）
讓我們測試一下下面這三種用來捕獲Widget異常的catch子句，異常是做為passAndThrowWidgetp拋出的：

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

我們立刻注意到了傳遞參數(shù)與傳遞異常的另一個差異.
一個被異常拋出的對象（剛才解釋過，總是一個臨時對象）可以通過普通的引用捕獲.
它不需要通過指向const對象的引用（reference-to-const）捕獲.
在函數(shù)調(diào)用中不允許轉(zhuǎn)遞一個臨時對象到一個非const引用類型的參數(shù)里（參見條款19），但是在異常中卻被允許.
讓我們先不管這個差異，回到異常對象拷貝的測試上來.
我們知道當(dāng)用傳值的方式傳遞函數(shù)的參數(shù)，我們制造了被傳遞對象的一個拷貝（參見Effective C++ 條款22），并把這個拷貝存儲到函數(shù)的參數(shù)里.
同樣我們通過傳值的方式傳遞一個異常時，也是這么做的。當(dāng)我們這樣聲明一個catch子句時:
catch (Widget w) ... // 通過傳值捕獲
會建立兩個被拋出對象的拷貝，一個是所有異常都必須建立的臨時對象，第二個是把臨時對象拷貝進w中.
同樣，當(dāng)我們通過引用捕獲異常時:
catch (Widget& w) ... // 通過引用捕獲

catch (const Widget& w) ... file://也通過引用捕獲
這仍舊會建立一個被拋出對象的拷貝：拷貝是一個臨時對象.
相反當(dāng)我們通過引用傳遞函數(shù)參數(shù)時，沒有進行對象拷貝.
當(dāng)拋出一個異常時，系統(tǒng)構(gòu)造的（以后會析構(gòu)掉）被拋出對象的拷貝數(shù)比以相同對象做為參數(shù)傳遞給函數(shù)時構(gòu)造的拷貝數(shù)要多一個.
我們還沒有討論通過指針拋出異常的情況，不過通過指針拋出異常與通過指針傳遞參數(shù)是相同的.
不論哪種方法都是一個指針的拷貝被傳遞.
你不能認為拋出的指針是一個指向局部對象的指針，因為當(dāng)異常離開局部變量的生存空間時，該局部變量已經(jīng)被釋放.
Catch子句將獲得一個指向已經(jīng)不存在的對象的指針。這種行為在設(shè)計時應(yīng)該予以避免.
對象從函數(shù)的調(diào)用處傳遞到函數(shù)參數(shù)里與從異常拋出點傳遞到catch子句里所采用的方法不同，
這只是參數(shù)傳遞與異常傳遞的區(qū)別的一個方面，第二個差異是在函數(shù)調(diào)用者或拋出異常者與被調(diào)用者或異常捕獲者之間的類型匹配的過程不同.
比如在標準數(shù)學(xué)庫（the standard math library）中sqrt函數(shù)：
double sqrt(double); // from <cmath> or <math.h>
我們能這樣計算一個整數(shù)的平方根，如下所示：
int i;
double sqrtOfi = sqrt(i);
毫無疑問，C++允許進行從int到double的隱式類型轉(zhuǎn)換，所以在sqrt的調(diào)用中，i 被悄悄地轉(zhuǎn)變?yōu)閐ouble類型，并且其返回值也是double.
（有關(guān)隱式類型轉(zhuǎn)換的詳細討論參見條款5）一般來說，catch子句匹配異常類型時不會進行這樣的轉(zhuǎn)換.
見下面的代碼：

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

在try塊中拋出的int異常不會被處理double異常的catch子句捕獲.
該子句只能捕獲真真正正為double類型的異常；不進行類型轉(zhuǎn)換.
因此如果要想捕獲int異常，必須使用帶有int或int&參數(shù)的catch子句.
不過在catch子句中進行異常匹配時可以進行兩種類型轉(zhuǎn)換.
第一種是繼承類與基類間的轉(zhuǎn)換.
一個用來捕獲基類的catch子句也可以處理派生類類型的異常.
例如在標準C++庫（STL）定義的異常類層次中的診斷部分（diagnostics portion ）(參見Effective C++ 條款49).
捕獲runtime_errors異常的Catch子句可以捕獲range_error類型和overflow_error類型的異常，
可以接收根類exception異常的catch子句能捕獲其任意派生類異常.
這種派生類與基類（inheritance_based）間的異常類型轉(zhuǎn)換可以作用于數(shù)值、引用以及指針上：

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）轉(zhuǎn)變成無類型指針（untyped pointer），
所以帶有const void* 指針的catch子句能捕獲任何類型的指針類型異常：
catch (const void*) ... file://捕獲任何指針類型異常

傳遞參數(shù)和傳遞異常間最后一點差別是catch子句匹配順序總是取決于它們在程序中出現(xiàn)的順序.
因此一個派生類異?？赡鼙惶幚砥浠惍惓５腸atch子句捕獲，即使同時存在有能處理該派生類異常的catch子句，與相同的try塊相對應(yīng).
例如：

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

與上面這種行為相反，當(dāng)你調(diào)用一個虛擬函數(shù)時，被調(diào)用的函數(shù)位于與發(fā)出函數(shù)調(diào)用的對象的動態(tài)類型（dynamic type）最相近的類里.
你可以這樣說虛擬函數(shù)采用最優(yōu)適合法，而異常處理采用的是最先適合法.
如果一個處理派生類異常的catch子句位于處理基類異常的catch子句前面，編譯器會發(fā)出警告.
（因為這樣的代碼在C++里通常是不合法的）
不過你最好做好預(yù)先防范：不要把處理基類異常的catch子句放在處理派生類異常的catch子句的前面.
上面那個例子，應(yīng)該這樣去寫：

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

綜上所述，把一個對象傳遞給函數(shù)或一個對象調(diào)用虛擬函數(shù)與把一個對象做為異常拋出，這之間有三個主要區(qū)別.
第一、異常對象在傳遞時總被進行拷貝；當(dāng)通過傳值方式捕獲時，異常對象被拷貝了兩次.
對象做為參數(shù)傳遞給函數(shù)時不需要被拷貝.
第二、對象做為異常被拋出與做為參數(shù)傳遞給函數(shù)相比，前者類型轉(zhuǎn)換比后者要少（前者只有兩種轉(zhuǎn)換形式）.
最后一點，catch子句進行異常類型匹配的順序是它們在源代碼中出現(xiàn)的順序，第一個類型匹配成功的catch將被用來執(zhí)行.
當(dāng)一個對象調(diào)用一個虛擬函數(shù)時，被選擇的函數(shù)位于與對象類型匹配最佳的類里，即使該類不是在源代碼的最前頭.
靈巧指針
第一次用到靈巧指針是在寫ADO代碼的時候，用到com_ptr_t靈巧指針；但一直印象不是很深；
其實靈巧指針的作用很大，對我們來說垃圾回收，ATL等都會使用到它.
在More effective 的條款后面特意增加這個節(jié)點，不僅是想介紹它在異常處理方面的作用，還希望對編寫別的類型代碼的時候可以有所幫助.
smart pointer（靈巧指針）其實并不是一個指針,其實是某種形式的類.
不過它的特長就是模仿C/C++中的指針，所以就叫pointer 了.
所以希望大家一定要記住兩點：smart pointer是一個類而非指針，但特長是模仿指針.
那怎么做到像指針的呢？
C++的模板技術(shù)和運算符重載給了很大的發(fā)揮空間.
首先smart pointer必須是高度類型化的（strongly typed ），模板給了這個功能.
其次需要模仿指針主要的兩個運算符->和*，那就需要進行運算符重載.
詳細的實現(xiàn)：

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 ，這都需要根據(jù)具體的應(yīng)用環(huán)境而定.
注意重載運算符*和->，正是它們使smart pointer看起來跟普通的指針很相像.
而由于smart pointer是一個類，在構(gòu)造函數(shù)、析構(gòu)函數(shù)中都可以通過恰當(dāng)?shù)木幊踢_到一些不錯的效果.
舉例：
比如C++標準庫里的std::auto_ptr 就是應(yīng)用很廣的一個例子.
它的實現(xiàn)在不同版本的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;
};

關(guān)于auto_ptr 的使用可以找到很多的列子，這里不在舉了.
它的主要優(yōu)點是不用 delete ，可以自動回收已經(jīng)被分配的空間，由此可以避免資源泄露的問題.
很多Java 的擁護者經(jīng)常不分黑白的污蔑C++沒有垃圾回收機制，其實不過是貽笑大方而已.
拋開在網(wǎng)上許許多多的商業(yè)化和非商業(yè)化的C++垃圾回收庫不提， auto_ptr 就足以有效地解決這一問題.
并且即使在產(chǎn)生異常的情況下， auto_ptr 也能正確地回收資源.
這對于寫出異常安全（exception-safe ）的代碼具有重要的意義.
在使用smart pointer 的過程中，要注意的問題：
針對不同的smart pointer ，有不同的注意事項。比如auto_ptr ，就不能把它用在標準容器里，因為它只在內(nèi)存中保留一份實例.
把握我前面說的兩個原則：smart pointer 是類而不是指針，是模仿指針，那么一切問題都好辦.
比如，smart pointer 作為一個類，那么以下的做法就可能有問題.

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

很顯然， p 不是一個真正的指針，這么做可能出錯.
而SmartPtr 的設(shè)計也是很重要的因素.
您可以加上一個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 !()等等方法來實現(xiàn).
總結(jié)smart pointer的實質(zhì)：
smart pointer 的實質(zhì)就是一個外殼，一層包裝。正是多了這層包裝，我們可以做出許多普通指針無法完成的事，比如前面資源自動回收，或者自動進行引用記數(shù)，比如ATL 中CComPtr 和 CComQIPtr 這兩個COM 接口指針類.
然而也會帶來一些副作用，正由于多了這些功能，又會使 smart pointer 喪失一些功能.

WIN結(jié)構(gòu)化異常

對使用WIN32平臺的人來說，對WIN的結(jié)構(gòu)化異常應(yīng)該要有所了解的。WINDOWS的結(jié)構(gòu)化異常是操作系統(tǒng)的一部分，而C++異常只是C++的一部分，當(dāng)我們用C++編寫代碼的時候，我們選擇C++的標準異常（也可以用MS VC的異常），編譯器會自動的把我們的C++標準異常轉(zhuǎn)化成SEH異常。

微軟的Visual C++也支持C + +的異常處理，并且在內(nèi)部實現(xiàn)上利用了已經(jīng)引入到編譯程序和Windows操作系統(tǒng)的結(jié)構(gòu)化異常處理的功能。

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

在MS VC的FAQ中有關(guān)于SEH的部分介紹，這里摘超其中的一句：

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

一定要記得在背后的事情：在使用SEH的時候，編譯程序和操作系統(tǒng)直接參與了程序代碼的執(zhí)行。

Win32異常事件的理解

我寫的另一篇文章：內(nèi)存處理和DLL技術(shù)也涉及到了SEH中的異常處理。

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

發(fā)生異常的時候，執(zhí)行流程終止，同時控制權(quán)轉(zhuǎn)交給操作系統(tǒng)，OS會用上下文（CONTEXT）結(jié)構(gòu)把當(dāng)前的進程狀態(tài)保存下來，然后就開始search 一個能處理exception的組件，search order如下：

1. 首先檢查是否有一個調(diào)試程序與發(fā)生exception的進程聯(lián)系在一起，推算這個調(diào)試程序是否有能力處理

2. 如上面不能完成，操作系統(tǒng)就在發(fā)生exception event的線程中search exception event handler

3. search與進程關(guān)聯(lián)在一起的調(diào)試程序

4. 系統(tǒng)執(zhí)行自己的exception event handler code and terminate process

結(jié)束處理程序

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

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

微軟在Windows中引入SEH的主要動機是為了便于操作系統(tǒng)本身的開發(fā).

操作系統(tǒng)的開發(fā)人員使用SEH，使得系統(tǒng)更加強壯.我們也可以使用SEH，使我們的自己的程序更加強壯.

使用SEH所造成的負擔(dān)主要由編譯程序來承擔(dān)，而不是由操作系統(tǒng)承擔(dān).

當(dāng)異常塊（exception block）出現(xiàn)時，編譯程序要生成特殊的代碼.

編譯程序必須產(chǎn)生一些表（table）來支持處理SEH的數(shù)據(jù)結(jié)構(gòu).

編譯程序還必須提供回調(diào)（callback）函數(shù)，操作系統(tǒng)可以調(diào)用這些函數(shù)，保證異常塊被處理.

編譯程序還要負責(zé)準備棧結(jié)構(gòu)和其他內(nèi)部信息，供操作系統(tǒng)使用和參考.

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

不同的編譯程序廠商會以不同的方式實現(xiàn)SEH，這一點并不讓人感到奇怪.

幸虧我們可以不必考慮編譯程序的實現(xiàn)細節(jié)，而只使用編譯程序的SEH功能.

（其實大多數(shù)編譯程序廠商都采用微軟建議的語法）

結(jié)束處理程序代碼初步

一個結(jié)束處理程序能夠確保去調(diào)用和執(zhí)行一個代碼塊（結(jié)束處理程序，termination handler），

而不管另外一段代碼（保護體， guarded body）是如何退出的。結(jié)束處理程序的語法結(jié)構(gòu)如下：

__try
{
file://保護塊
}
__finally
{
file://結(jié)束處理程序
}

 在上面的代碼段中，操作系統(tǒng)和編譯程序共同來確保結(jié)束處理程序中的__f i n a l l y代碼塊能夠被執(zhí)行，不管保護體（t r y塊）是如何退出的。不論你在保護體中使用r e t u r n，還是g o t o，或者是longjump，結(jié)束處理程序（f i n a l l y塊）都將被調(diào)用。

=====================
************************
我們來看一個實列：（返回值：10, 沒有Leak，性能消耗：?。?/p>

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;
}

這段代碼應(yīng)該只是做為一個基礎(chǔ)函數(shù)，我們將在后面修改它，來看看結(jié)束處理程序的作用.
在代碼加一句：（返回值：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語句告訴編譯程序在這里要退出這個函數(shù)并返回dwTemp變量的內(nèi)容，現(xiàn)在這個變量的值是5.
但是，如果這個return語句被執(zhí)行，該線程將不會釋放信標，其他線程也就不能再獲得對信標的控制.
可以想象，這樣的執(zhí)行次序會產(chǎn)生很大的問題，那些等待信標的線程可能永遠不會恢復(fù)執(zhí)行.
通過使用結(jié)束處理程序，可以避免return語句的過早執(zhí)行.
當(dāng)return語句試圖退出try塊時，編譯程序要確保finally塊中的代碼首先被執(zhí)行.
要保證finally塊中的代碼在try塊中的return語句退出之前執(zhí)行.
在程序中，將ReleaseSemaphore的調(diào)用放在結(jié)束處理程序塊中，保證信標總會被釋放.

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

在finally塊中的代碼執(zhí)行之后，函數(shù)實際上就返回.

任何出現(xiàn)在finally塊之下的代碼將不再執(zhí)行，因為函數(shù)已在try塊中返回,所以這個函數(shù)的返回值是5，而不是10.

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

當(dāng)編譯程序檢查源代碼時，它看到在try塊中有return語句.

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

編譯程序然后再生成代碼來執(zhí)行finally塊中包含的指令，這稱為局部展開.

更特殊的情況是，由于try塊中存在過早退出的代碼，從而產(chǎn)生局部展開，導(dǎo)致系統(tǒng)執(zhí)行finally塊中的內(nèi)容.

在finally塊中的指令執(zhí)行之后，編譯程序臨時變量的值被取出并從函數(shù)中返回.

可以看到，要完成這些事情，編譯程序必須生成附加的代碼，系統(tǒng)要執(zhí)行額外的工作.

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

例如，在Alpha處理器上，必須執(zhí)行幾百個甚至幾千個CPU指令來捕捉try塊中的過早返回并調(diào)用finally塊.

在編寫代碼時，就應(yīng)該避免引起結(jié)束處理程序的try塊中的過早退出，因為程序的性能會受到影響.

后面，將討論__leave關(guān)鍵字，它有助于避免編寫引起局部展開的代碼.

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

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

注意當(dāng)控制流自然地離開try塊并進入finally塊（就像在Funcenstein1中）時，進入finally塊的系統(tǒng)開銷是最小的.

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

當(dāng)編譯程序要生成額外的代碼，系統(tǒng)要執(zhí)行額外的工作時系統(tǒng)開銷就很值得注意了.

========================
修改代碼：（返回值：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;
}

代碼中，當(dāng)編譯程序看到try塊中的goto語句，它首先生成一個局部展開來執(zhí)行finally塊中的內(nèi)容.
這一次，在finally塊中的代碼執(zhí)行之后，在ReturnValue標號之后的代碼將執(zhí)行，因為在try塊和finally塊中都沒有返回發(fā)生.
這里的代碼使函數(shù)返回5,而且，由于中斷了從try塊到finally塊的自然流程，可能要蒙受很大的性能損失（取決于運行程序的CPU）

寫上面的代碼是初步的，現(xiàn)在來看結(jié)束處理程序在我們代碼里面的真正的價值：
看代碼：（信號燈被正常釋放，reserve的一頁內(nèi)存沒有被Free，安全性：安全）

DWORD TermHappenSomeError()
{
   DWORD dwReturnValue = 9;
   DWORD dwMemorySize = 1024;
   
   char* lpAddress;
   lpAddress = (char*)VirtualAlloc(NULL, dwMemorySize, MEM_RESERVE, PAGE_READWRITE);
}

finally塊的總結(jié)性說明

我們已經(jīng)明確區(qū)分了強制執(zhí)行finally塊的兩種情況：

從try塊進入finally塊的正?？刂屏?

•局部展開：從try塊的過早退出（goto、longjump、continue、break、return等）強制控制轉(zhuǎn)移到finally塊.

第三種情況，全局展開（globalunwind），在發(fā)生的時候沒有明顯的標識，我們在本章前面Func_SEHTerminate函數(shù)中已經(jīng)見到.在Func_SEHTerminate的try塊中，有一個對TermHappenSomeError函數(shù)的調(diào)用。TermHappenSomeError函數(shù)會引起一個內(nèi)存訪問違規(guī)（memory access violation），一個全局展開會使Func_SEHTerminate函數(shù)的finally塊執(zhí)行.

由于以上三種情況中某一種的結(jié)果而導(dǎo)致finally塊中的代碼開始執(zhí)行。為了確定是哪一種情況引起finally塊執(zhí)行，可以調(diào)用內(nèi)部函數(shù)AbnormalTermination：這個內(nèi)部函數(shù)只在finally塊中調(diào)用，返回一個Boolean值.指出與finally塊相結(jié)合的try塊是否過早退出。換句話說，如果控制流離開try塊并自然進入finally塊，AbnormalTermination將返回FALSE。如果控制流非正常退出try塊—通常由于goto、return、break或continue語句引起的局部展開，或由于內(nèi)存訪問違規(guī)或其他異常引起的全局展開—對AbnormalTermination的調(diào)用將返回TRUE。沒有辦法區(qū)別finally塊的執(zhí)行是由于全局展開還是由于局部展開.

但這通常不會成為問題，因為可以避免編寫執(zhí)行局部展開的代碼.（注意內(nèi)部函數(shù)是編譯程序識別的一種特殊函數(shù)。編譯程序為內(nèi)部函數(shù)產(chǎn)生內(nèi)聯(lián)（inline）代碼而不是生成調(diào)用函數(shù)的代碼。例如，memcpy是一個內(nèi)部函數(shù)（如果指定/Oi編譯程序開關(guān)）。當(dāng)編譯程序看到一個對memcpy的調(diào)用，它直接將memcpy的代碼插入調(diào)用memcpy的函數(shù)中，而不是生成一個對memcpy函數(shù)的調(diào)用。其作用是代碼的長度增加了，但執(zhí)行速度加快了。

在繼續(xù)之前，回顧一下使用結(jié)束處理程序的理由：

•簡化錯誤處理，因所有的清理工作都在一個位置并且保證被執(zhí)行。

•提高程序的可讀性。

•使代碼更容易維護。

•如果使用得當(dāng)，具有最小的系統(tǒng)開銷。

異常處理程序

異常是我們不希望有的事件。在編寫程序的時候，程序員不會想去存取一個無效的內(nèi)存地址或用0來除一個數(shù)值。不過，這樣的錯誤還是常常會發(fā)生的。CPU負責(zé)捕捉無效內(nèi)存訪問和用0除一個數(shù)值這種錯誤，并相應(yīng)引發(fā)一個異常作為對這些錯誤的反應(yīng)。CPU引發(fā)的異常，就是所謂的硬件異常（hardwareexception）。在本章的后面，我們還會看到操作系統(tǒng)和應(yīng)用程序也可以引發(fā)相應(yīng)的異常，稱為軟件異常（softwareexception）。

當(dāng)出現(xiàn)一個硬件或軟件異常時，操作系統(tǒng)向應(yīng)用程序提供機會來考察是什么類型的異常被引發(fā)，并能夠讓應(yīng)用程序自己來處理異常。下面就是異常處理程序的語法：

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

注意__ e x c e p t關(guān)鍵字。每當(dāng)你建立一個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塊，反過來也可以。
異常處理程序代碼初步
與結(jié)束處理程序不同，異常過濾器（ exception filter）和異常處理程序是通過操作系統(tǒng)直接執(zhí)行的，編譯程序在計算異常過濾器表達式和執(zhí)行異常處理程序方面不做什么事。下面幾節(jié)的內(nèi)容舉例說明t r y - e x c e p t塊的正常執(zhí)行，解釋操作系統(tǒng)如何以及為什么計算異常過濾器，并給出操作系統(tǒng)執(zhí)行異常處理程序中代碼的環(huán)境。
本來想把代碼全部寫出來的，但是實在是寫這邊文擋化的時間太長了，所以接下來就只是做說明，而且try和except塊比較簡單。
盡管在結(jié)束處理程序的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塊中使用這些語句不會產(chǎn)生速度和代碼規(guī)模方面的不良影響。這樣的語句出現(xiàn)在與e x c e p t塊相結(jié)合的t r y塊中不會引起局部展開的系統(tǒng)開銷
當(dāng)引發(fā)了異常時，系統(tǒng)將定位到e x c e p t塊的開頭，并計算異常過濾器表達式的值，過濾器表達式的結(jié)果值只能是下面三個標識符之一，這些標識符定義在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

下面將討論這些標識符如何改變線程的執(zhí)行。

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

*****開始 -> 執(zhí)行一個CPU指令 -> {是否有異常被引發(fā)} -> 是 -> 系統(tǒng)確定最里層的try 塊 -> {這個try塊是否有一個except塊} -> 是 -> {過濾器表達式的值是什么} ->異常執(zhí)行處理程序 -> 全局展開開始 -> 執(zhí)行except塊中的代碼 -> 在except塊之后執(zhí)行繼續(xù)*****

EXCEPTION_EXECUTE_HANDLER

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

即，我感覺這個異?？赡茉谀硞€時候發(fā)生，我已編寫了代碼來處理這個問題，現(xiàn)在我想執(zhí)行這個代碼”

在這個時候，系統(tǒng)執(zhí)行一個全局展開，然后執(zhí)行向except塊中代碼（異常處理程序代碼）的跳轉(zhuǎn).

在except塊中代碼執(zhí)行完之后，系統(tǒng)考慮這個要被處理的異常并允許應(yīng)用程序繼續(xù)執(zhí)行。這種機制使windows應(yīng)用程序可以抓住錯誤并處理錯誤，再使程序繼續(xù)運行，不需要用戶知道錯誤的發(fā)生。但是，當(dāng)except塊執(zhí)行后，代碼將從何處恢復(fù)執(zhí)行？稍加思索，我們就可以想到幾種可能性:

第一種可能性是從產(chǎn)生異常的CPU指令之后恢復(fù)執(zhí)行。這看起來像是合理的做法，但實際上，很多程序的編寫方式使得當(dāng)前面的指令出錯時，后續(xù)的指令不能夠繼續(xù)成功地執(zhí)行。代碼應(yīng)該盡可能地結(jié)構(gòu)化，這樣，在產(chǎn)生異常的指令之后的CPU指令有望獲得有效的返回值。例如，可能有一個指令分配內(nèi)存，后面一系列指令要執(zhí)行對該內(nèi)存的操作。如果內(nèi)存不能夠被分配，則所有后續(xù)的指令都將失敗，上面這個程序重復(fù)地產(chǎn)生異常。所幸的是，微軟沒有讓系統(tǒng)從產(chǎn)生異常的指令之后恢復(fù)指令的執(zhí)行。這種決策使我們免于面對上面的問題。

第二種可能性是從產(chǎn)生異常的指令恢復(fù)執(zhí)行。這是很有意思的可能性。如果在except塊中

有這樣的語句會怎么樣呢：在except塊中有了這個賦值語句，可以從產(chǎn)生異常的指令恢復(fù)執(zhí)行。這一次，執(zhí)行將繼續(xù)，不會產(chǎn)生其他的異常?？梢宰鲂┬薷?，讓系統(tǒng)重新執(zhí)行產(chǎn)生異常的指令。你會發(fā)現(xiàn)這種方法將導(dǎo)致某些微妙的行為。我們將在EXCEPTION_CONTINUE_EXECUTION一節(jié)中討論這種技術(shù)。

第三種可能性是從except塊之后的第一條指令開始恢復(fù)執(zhí)行。這實際是當(dāng)異常過濾器表達式的值為EXCEPTION_EXECUTE_HANDLER時所發(fā)生的事。在except塊中的代碼結(jié)束執(zhí)行后，控制從except塊之后的第一條指令恢復(fù)。

c++異常參數(shù)傳遞

從語法上看，在函數(shù)里聲明參數(shù)與在catch子句中聲明參數(shù)是一樣的，catch里的參數(shù)可以是值類型，引用類型，指針類型.例如：

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

盡管表面是它們是一樣的，但是編譯器對二者的處理卻又很大的不同.
調(diào)用函數(shù)時，程序的控制權(quán)最終還會返回到函數(shù)的調(diào)用處，但是拋出一個異常時，控制權(quán)永遠不會回到拋出異常的地方.

class A;
void func_throw()
{
   A a;
   throw a; //拋出的是a的拷貝，拷貝到一個臨時對象里
}
try
{
   func_throw();
}
catch(A a) //臨時對象的拷貝
{
}

當(dāng)我們拋出一個異常對象時，拋出的是這個異常對象的拷貝。當(dāng)異常對象被拷貝時，拷貝操作是由對象的拷貝構(gòu)造函數(shù)完成的.
該拷貝構(gòu)造函數(shù)是對象的靜態(tài)類型(static type)所對應(yīng)類的拷貝構(gòu)造函數(shù)，而不是對象的動態(tài)類型(dynamic type)對應(yīng)類的拷貝構(gòu)造函數(shù)。此時對象會丟失RTTI信息.
異常是其它對象的拷貝，這個事實影響到你如何在catch塊中再拋出一個異常。比如下面這兩個catch塊，乍一看好像一樣:

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

第一個塊中重新拋出的是當(dāng)前異常(current exception),無論它是什么類型。（有可能是A的派生類）
第二個catch塊重新拋出的是新異常，失去了原來的類型信息.
一般來說，你應(yīng)該用throw來重新拋出當(dāng)前的異常，因為這樣不會改變被傳遞出去的異常類型，而且更有效率，因為不用生成一個新拷貝.
看看以下這三種聲明:
catch (A w) ... // 通過傳值
catch (A& w) ... // 通過傳遞引用
catch (const A& w) ... //const引用
一個被異常拋出的對象(總是一個臨時對象)可以通過普通的引用捕獲;它不需要通過指向const對象的引用(reference-to-const)捕獲.
在函數(shù)調(diào)用中不允許轉(zhuǎn)遞一個臨時對象到一個非const引用類型的參數(shù)里，但是在異常中卻被允許.
回到異常對象拷貝上來,我們知道，當(dāng)用傳值的方式傳遞函數(shù)的參數(shù)，我們制造了被傳遞對象的一個拷貝，并把這個拷貝存儲到函數(shù)的參數(shù)里.
同樣我們通過傳值的方式傳遞一個異常時，也是這么做的當(dāng)我們這樣聲明一個catch子句時:
catch (A w) ... // 通過傳值捕獲
會建立兩個被拋出對象的拷貝，一個是所有異常都必須建立的臨時對象，第二個是把臨時對象拷貝進w中。實際上，編譯器會優(yōu)化掉一個拷貝。同樣，當(dāng)我們通過引用捕獲異常時，
catch (A& w) ... // 通過引用捕獲
catch (const A& w) ... //const引用捕獲
這仍舊會建立一個被拋出對象的拷貝:拷貝是一個臨時對象。相反當(dāng)我們通過引用傳遞函數(shù)參數(shù)時，沒有進行對象拷貝.
話雖如此，但是不是所有編譯器都如此,VS200就表現(xiàn)很詭異.
通過指針拋出異常與通過指針傳遞參數(shù)是相同的.
不論哪種方法都是一個指針的拷貝被傳遞,你不能認為拋出的指針是一個指向局部對象的指針，因為當(dāng)異常離開局部變量的生存空間時，該局部變量已經(jīng)被釋放.
Catch子句將獲得一個指向已經(jīng)不存在的對象的指針。這種行為在設(shè)計時應(yīng)該予以避免.
另外一個重要的差異是在函數(shù)調(diào)用者或拋出異常者與被調(diào)用者或異常捕獲者之間的類型匹配的過程不同.
在函數(shù)傳遞參數(shù)時，如果參數(shù)不匹配，那么編譯器會嘗試一個類型轉(zhuǎn)換，如果存在的話。而對于異常處理的話，則完全不是這樣。見一下的例子：

void func_throw()
{
   CString a;
   throw a; //拋出的是a的拷貝，拷貝到一個臨時對象里
}
try
{
   func_throw();
}
catch(const char* s)
{
   
}

拋出的是CString，如果用const char*來捕獲的話，是捕獲不到這個異常的.
盡管如此，在catch子句中進行異常匹配時可以進行兩種類型轉(zhuǎn)換.第一種是基類與派生類的轉(zhuǎn)換，一個用來捕獲基類的catch子句也可以處理派生類類型的異常.
反過來，用來捕獲派生類的無法捕獲基類的異常.

第二種是允許從一個類型化指針(typed pointer)轉(zhuǎn)變成無類型指針(untyped pointer)，所以帶有const void* 指針的catch子句能捕獲任何類型的指針類型異常:
catch (const void*) ... //可以捕獲所有指針異常
另外，你還可以用catch(...)來捕獲所有異常，注意是三個點.
傳遞參數(shù)和傳遞異常間最后一點差別是catch子句匹配順序總是取決于它們在程序中出現(xiàn)的順序.
因此一個派生類異?？赡鼙惶幚砥浠惍惓５腸atch子句捕獲，這叫異常截獲，一般的編譯器會有警告.

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() ;
}

相反的是，當(dāng)你調(diào)用一個虛擬函數(shù)時，被調(diào)用的函數(shù)位于與發(fā)出函數(shù)調(diào)用的對象的動態(tài)類型(dynamic type)最相近的類里.

你可以這樣說虛擬函數(shù)匹配采用最優(yōu)匹配法，而異常處理匹配采用的是最先匹配法.

附：
異常的描述
函數(shù)和函數(shù)可能拋出的異常集合作為函數(shù)聲明的一部分是有價值的，例如

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

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

如果f函數(shù)違反了這個規(guī)定，拋出了x2,x3之外的異常,例如x4,那么當(dāng)函數(shù)f拋出x4異常時，

會轉(zhuǎn)換為一個std::unexpected()調(diào)用，默認是調(diào)用std::terminate(),通常是調(diào)用abort().

如果函數(shù)不帶異常描述，那么假定他可能拋出任何異常,例如:

int f(); //可能拋出任何異常

不帶任何異常的函數(shù)可以用空表表示:

int g() throw(); // 不會拋出任何異常

本文章部分內(nèi)容參考hellodev的博客 

最新評論