寫(xiě)在前面

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

　　異常處理的基本思想是簡(jiǎn)化程序的錯(cuò)誤代碼，為程序鍵壯性提供一個(gè)標(biāo)準(zhǔn)檢測(cè)機(jī)制.

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

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

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

本文包括2個(gè)大的異常實(shí)現(xiàn)概念：C++的標(biāo)準(zhǔn)異常和SEH異常.

　　C++標(biāo)準(zhǔn)異常：

　　也許你很高興看到錯(cuò)誤之后的Heap/Stack中對(duì)象被釋放，可是如果沒(méi)有呢？

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

　　 在《C++標(biāo)準(zhǔn)異?！分形蚁蚰阃扑]這幾章：

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

　　SEH異常：

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

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

　　　　SEH功能強(qiáng)大，包括Termination handling和Exception handling兩大部分.

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

　　　　在SEH中有大量的代碼，已經(jīng)在Win平臺(tái)上測(cè)試過(guò)了.

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

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

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

用2個(gè)列子，講述了我們一般都會(huì)犯下的錯(cuò)誤，往往這種錯(cuò)誤是我們沒(méi)有意識(shí)到的但確實(shí)是會(huì)給我們的軟件帶來(lái)致命的Leak/Crash，但這是有解決的方法的，那就是使用“靈巧指針”.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

對(duì)C程序來(lái)說(shuō)，使用Error Code就可以了，為什么還要引入異常？因?yàn)楫惓２荒鼙缓雎?

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

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

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

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

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

所以我們需要一個(gè)方法：

　?、倌軌蛲ㄖ惓顟B(tài)，又不能忽略這個(gè)通知.

　　②并且Searching the stack以便找到異常代碼時(shí).

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

而C++的異常處理剛好就是來(lái)解決這些問(wèn)題的.

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

還有，異常處理的使用呢，可以使出錯(cuò)處理程序與“通?！贝a分離開(kāi)來(lái)，使代碼更簡(jiǎn)潔更靈活.

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

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

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

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

throw異常類(lèi)編程,拋出異常用throw， 如：

throw ExceptionClass(“my throw“);

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

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

看下面這個(gè)程序：

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

不過(guò)一般來(lái)說(shuō)我們可能更習(xí)慣于把會(huì)產(chǎn)生異常的語(yǔ)句和要throw的異常類(lèi)分成不同的類(lèi)來(lái)寫(xiě)，下面的代碼可以是我們更愿意書(shū)寫(xiě)的.

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ù)，里面有異常拋出，用去查看它的源代碼去看看都有什么異常拋出嗎？這樣就會(huì)很煩瑣.
比較好的解決辦法，是編寫(xiě)帶有異常拋出的函數(shù)時(shí)，采用異常規(guī)格說(shuō)明，使我們看到函數(shù)聲明就知道有哪些異常出現(xiàn)。
異常規(guī)格說(shuō)明大體上為以下格式：

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

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

void ExceptionFunction(argument…) throw()

表明沒(méi)有任何異常拋出.

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

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

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

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

標(biāo)準(zhǔn)C++異常類(lèi)

C++有自己的標(biāo)準(zhǔn)的異常類(lèi).
① 一個(gè)基類(lèi)：
exception 是所有C++異常的基類(lèi).

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

② 下面派生了兩個(gè)異常類(lèi)：

logic_erro 報(bào)告程序的邏輯錯(cuò)誤，可在程序執(zhí)行前被檢測(cè)到.

runtime_erro 報(bào)告程序運(yùn)行時(shí)的錯(cuò)誤，只有在運(yùn)行的時(shí)候才能檢測(cè)到.

以上兩個(gè)又分別有自己的派生類(lèi)：
③ 由logic_erro派生的異常類(lèi)

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

④ 由runtime_error派生的異常

range_error　　　　 報(bào)告違反了后置條件
overflow_error 　　報(bào)告一個(gè)算術(shù)溢出
bad_alloc 報(bào)告一個(gè)存儲(chǔ)分配錯(cuò)誤

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

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

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

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

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

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

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

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

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

這個(gè)函數(shù)循環(huán)遍歷dataSource內(nèi)的信息，處理它所遇到的每個(gè)項(xiàng)目.
唯一要記住的一點(diǎn)是在每次循環(huán)結(jié)尾處刪除ps.
這是必須的，因?yàn)槊看握{(diào)用readALA都建立一個(gè)堆對(duì)象.如果不刪除對(duì)象，循環(huán)將產(chǎn)生資源泄漏。
現(xiàn)在考慮一下，如果pa->processAdoption拋出了一個(gè)異常，將會(huì)發(fā)生什么？
processAdoptions沒(méi)有捕獲異常，所以異常將傳遞給processAdoptions的調(diào)用者.
轉(zhuǎn)遞中，processAdoptions函數(shù)中的調(diào)用pa->processAdoption語(yǔ)句后的所有語(yǔ)句都被跳過(guò)，這就是說(shuō)pa沒(méi)有被刪除.
結(jié)果，任何時(shí)候pa->processAdoption拋出一個(gè)異常都會(huì)導(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)異常拋出時(shí)
         throw; 　　　　　　　　　 // 傳送異常給調(diào)用者
      }
      delete pa; 　　　　　　　　 // 避免資源泄漏
   }　　　　　　　　　　　　　 // 當(dāng)沒(méi)有異常拋出時(shí)
}

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

下面所示的是auto_ptr類(lèi)的一些重要的部分：

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

auto_ptr類(lèi)的完整代碼是非常有趣的，上述簡(jiǎn)化的代碼實(shí)現(xiàn)不能在實(shí)際中應(yīng)用.
（我們至少必須加上拷貝構(gòu)造函數(shù)，賦值operator以及下面將要講到的pointer-emulating函數(shù)）
但是它背后所蘊(yùn)含的原理應(yīng)該是清楚的：用auto_ptr對(duì)象代替raw指針，你將不再為堆對(duì)象不能被刪除而擔(dān)心，即使在拋出異常時(shí)，對(duì)象也能被及時(shí)刪除.
(因?yàn)閍uto_ptr的析構(gòu)函數(shù)使用的是單對(duì)象形式的delete，所以auto_ptr不能用于指向?qū)ο髷?shù)組的指針.
如果想讓auto_ptr類(lèi)似于一個(gè)數(shù)組模板，你必須自己寫(xiě)一個(gè)。在這種情況下，用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對(duì)象代替raw指針，processAdoptions如下所示：

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

這個(gè)版本的processAdoptions在兩個(gè)方面區(qū)別于原來(lái)的processAdoptions函數(shù).
第一， pa被聲明為一個(gè)auto_ptr<ALA>對(duì)象，而不是一個(gè)raw ALA*指針.
第二， 在循環(huán)的結(jié)尾沒(méi)有delete語(yǔ)句.
其余部分都一樣，因?yàn)槌宋鰳?gòu)的方式，auto_ptr對(duì)象的行為就象一個(gè)普通的指針。是不是很容易.
隱藏在auto_ptr后的思想是：
　　用一個(gè)對(duì)象存儲(chǔ)需要被自動(dòng)釋放的資源，然后依靠對(duì)象的析構(gòu)函數(shù)來(lái)釋放資源，這種思想不只是可以運(yùn)用在指針上，還能用在其它資源的分配和釋放上.
想一下這樣一個(gè)在GUI程序中的函數(shù)，它需要建立一個(gè)window來(lái)顯式一些信息：
// 這個(gè)函數(shù)會(huì)發(fā)生資源泄漏，如果一個(gè)異常拋出

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

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

//一個(gè)類(lèi)，獲取和釋放一個(gè)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ù)被聲明為私有，防止建立多個(gè)WINDOW_HANDLE拷貝
   //有關(guān)一個(gè)更靈活的方法的討論請(qǐng)參見(jiàn)下面的靈巧指針
   　WindowHandle(const WindowHandle&);
   　WindowHandle& operator=(const WindowHandle&);
};

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

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

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

class Widget { ... }; //一個(gè)類(lèi)，具體是什么類(lèi)在這里并不重要
void f1(Widget w); // 一些函數(shù)，其參數(shù)分別為
void f2(Widget& w); // Widget, Widget&,或
void f3(const Widget& w); // Widget* 類(lèi)型
void f4(Widget *pw);
void f5(const Widget *pw);
catch(Widget w) ... //一些catch 子句，用來(lái)
catch(Widget& w) ... //捕獲異常，異常的類(lèi)型為
catch(const Widget& w) ... // Widget, Widget&, 或
catch(Widget *pw) ... // Widget*
catch(const Widget *pw) ...

你因此可能會(huì)認(rèn)為用throw拋出一個(gè)異常到catch子句中與通過(guò)函數(shù)調(diào)用傳遞一個(gè)參數(shù)兩者基本相同.
這里面確有一些相同點(diǎn)，但是他們也存在著巨大的差異.
讓我們先從相同點(diǎn)談起.
你傳遞函數(shù)參數(shù)與異常的途徑可以是傳值、傳遞引用或傳遞指針，這是相同的.
但是當(dāng)你傳遞參數(shù)和異常時(shí)，系統(tǒng)所要完成的操作過(guò)程則是完全不同的.
產(chǎn)生這個(gè)差異的原因是：你調(diào)用函數(shù)時(shí)，程序的控制權(quán)最終還會(huì)返回到函數(shù)的調(diào)用處，但是當(dāng)你拋出一個(gè)異常時(shí)，控制權(quán)永遠(yuǎn)不會(huì)回到拋出異常的地方。
有這樣一個(gè)函數(shù)，參數(shù)類(lèi)型是Widget，并拋出一個(gè)Widget類(lèi)型的異常：

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

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

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

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

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

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

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

這兩個(gè)catch塊的差別在于第一個(gè)catch塊中重新拋出的是當(dāng)前捕獲的異常，而第二個(gè)catch塊中重新拋出的是當(dāng)前捕獲異常的一個(gè)新的拷貝.
如果忽略生成額外拷貝的系統(tǒng)開(kāi)銷(xiāo)，這兩種方法還有差異么？
當(dāng)然有。第一個(gè)塊中重新拋出的是當(dāng)前異常（current exception）,無(wú)論它是什么類(lèi)型.
特別是如果這個(gè)異常開(kāi)始就是做為SpecialWidget類(lèi)型拋出的，那么第一個(gè)塊中傳遞出去的還是SpecialWidget異常，即使w的靜態(tài)類(lèi)型（static type）是Widget.
這是因?yàn)橹匦聮伋霎惓r(shí)沒(méi)有進(jìn)行拷貝操作.
第二個(gè)catch塊重新拋出的是新異常，類(lèi)型總是Widget，因?yàn)閣的靜態(tài)類(lèi)型（static type）是Widget.
一般來(lái)說(shuō)，你應(yīng)該用throw來(lái)重新拋出當(dāng)前的異常，因?yàn)檫@樣不會(huì)改變被傳遞出去的異常類(lèi)型，而且更有效率，因?yàn)椴挥蒙梢粋€(gè)新拷貝.
（順便說(shuō)一句，異常生成的拷貝是一個(gè)臨時(shí)對(duì)象.
正如條款19解釋的，臨時(shí)對(duì)象能讓編譯器優(yōu)化它的生存期（optimize it out of existence），
不過(guò)我想你的編譯器很難這么做，因?yàn)槌绦蛑泻苌侔l(fā)生異常，所以編譯器廠商不會(huì)在這方面花大量的精力）
讓我們測(cè)試一下下面這三種用來(lái)捕獲Widget異常的catch子句，異常是做為passAndThrowWidgetp拋出的：

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

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

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

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

在try塊中拋出的int異常不會(huì)被處理double異常的catch子句捕獲.
該子句只能捕獲真真正正為double類(lèi)型的異常；不進(jìn)行類(lèi)型轉(zhuǎn)換.
因此如果要想捕獲int異常，必須使用帶有int或int&參數(shù)的catch子句.
不過(guò)在catch子句中進(jìn)行異常匹配時(shí)可以進(jìn)行兩種類(lèi)型轉(zhuǎn)換.
第一種是繼承類(lèi)與基類(lèi)間的轉(zhuǎn)換.
一個(gè)用來(lái)捕獲基類(lèi)的catch子句也可以處理派生類(lèi)類(lèi)型的異常.
例如在標(biāo)準(zhǔn)C++庫(kù)（STL）定義的異常類(lèi)層次中的診斷部分（diagnostics portion ）(參見(jiàn)Effective C++ 條款49).
捕獲runtime_errors異常的Catch子句可以捕獲range_error類(lèi)型和overflow_error類(lèi)型的異常，
可以接收根類(lèi)exception異常的catch子句能捕獲其任意派生類(lèi)異常.
這種派生類(lèi)與基類(lèi)（inheritance_based）間的異常類(lèi)型轉(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*

第二種是允許從一個(gè)類(lèi)型化指針（typed pointer）轉(zhuǎn)變成無(wú)類(lèi)型指針（untyped pointer），
所以帶有const void* 指針的catch子句能捕獲任何類(lèi)型的指針類(lèi)型異常：
catch (const void*) ... file://捕獲任何指針類(lèi)型異常

傳遞參數(shù)和傳遞異常間最后一點(diǎn)差別是catch子句匹配順序總是取決于它們?cè)诔绦蛑谐霈F(xiàn)的順序.
因此一個(gè)派生類(lèi)異?？赡鼙惶幚砥浠?lèi)異常的catch子句捕獲，即使同時(shí)存在有能處理該派生類(lèi)異常的catch子句，與相同的try塊相對(duì)應(yīng).
例如：

try
{
   ...
}
catch(logic_error& ex)         // 這個(gè)catch塊 將捕獲
{
   ...                 // 所有的logic_error
}                   // 異常, 包括它的派生類(lèi)
catch(invalid_argument& ex)      // 這個(gè)塊永遠(yuǎn)不會(huì)被執(zhí)行
{
   ...                  //因?yàn)樗械膇nvalid_argument異常 都被上面的catch子句捕獲
}

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

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

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

這只是一個(gè)大概的印象，很多東西是可以更改的.
比如可以去掉或加上一些const ，這都需要根據(jù)具體的應(yīng)用環(huán)境而定.
注意重載運(yùn)算符*和->，正是它們使smart pointer看起來(lái)跟普通的指針很相像.
而由于smart pointer是一個(gè)類(lèi)，在構(gòu)造函數(shù)、析構(gòu)函數(shù)中都可以通過(guò)恰當(dāng)?shù)木幊踢_(dá)到一些不錯(cuò)的效果.
舉例：
比如C++標(biāo)準(zhǔn)庫(kù)里的std::auto_ptr 就是應(yīng)用很廣的一個(gè)例子.
它的實(shí)現(xiàn)在不同版本的STL 中雖有不同，但原理都是一樣，大概是下面這個(gè)樣子：

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)點(diǎn)是不用 delete ，可以自動(dòng)回收已經(jīng)被分配的空間，由此可以避免資源泄露的問(wèn)題.
很多Java 的擁護(hù)者經(jīng)常不分黑白的污蔑C++沒(méi)有垃圾回收機(jī)制，其實(shí)不過(guò)是貽笑大方而已.
拋開(kāi)在網(wǎng)上許許多多的商業(yè)化和非商業(yè)化的C++垃圾回收庫(kù)不提， auto_ptr 就足以有效地解決這一問(wèn)題.
并且即使在產(chǎn)生異常的情況下， auto_ptr 也能正確地回收資源.
這對(duì)于寫(xiě)出異常安全（exception-safe ）的代碼具有重要的意義.
在使用smart pointer 的過(guò)程中，要注意的問(wèn)題：
針對(duì)不同的smart pointer ，有不同的注意事項(xiàng)。比如auto_ptr ，就不能把它用在標(biāo)準(zhǔn)容器里，因?yàn)樗辉趦?nèi)存中保留一份實(shí)例.
把握我前面說(shuō)的兩個(gè)原則：smart pointer 是類(lèi)而不是指針，是模仿指針，那么一切問(wèn)題都好辦.
比如，smart pointer 作為一個(gè)類(lèi)，那么以下的做法就可能有問(wèn)題.

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

很顯然， p 不是一個(gè)真正的指針，這么做可能出錯(cuò).
而SmartPtr 的設(shè)計(jì)也是很重要的因素.
您可以加上一個(gè)bool SmartPtr::null() const 來(lái)進(jìn)行判斷.
如果堅(jiān)持非要用上面的形式， 那也是可以的,我們就加上operator void* ()試試：

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

這種方法在basic_ios 中就使用過(guò)了。這里也可以更靈活地處理，比如類(lèi)本身需要operator void*()這樣地操作，
那么上面這種方法就不靈了。但我們還有重載operator !()等等方法來(lái)實(shí)現(xiàn).
總結(jié)smart pointer的實(shí)質(zhì)：
smart pointer 的實(shí)質(zhì)就是一個(gè)外殼，一層包裝。正是多了這層包裝，我們可以做出許多普通指針無(wú)法完成的事，比如前面資源自動(dòng)回收，或者自動(dòng)進(jìn)行引用記數(shù)，比如ATL 中CComPtr 和 CComQIPtr 這兩個(gè)COM 接口指針類(lèi).
然而也會(huì)帶來(lái)一些副作用，正由于多了這些功能，又會(huì)使 smart pointer 喪失一些功能.

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

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

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

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

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

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

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

Win32異常事件的理解

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

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

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

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

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

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

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

結(jié)束處理程序

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

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

微軟在Windows中引入SEH的主要?jiǎng)訖C(jī)是為了便于操作系統(tǒng)本身的開(kāi)發(fā).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

這樣就不會(huì)造成一個(gè)線程一直占有信標(biāo)，否則將意味著所有其他等待信標(biāo)的線程永遠(yuǎn)不會(huì)被分配CPU時(shí)間.

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

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

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

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

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

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

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

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

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

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

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

在編寫(xiě)代碼時(shí)，就應(yīng)該避免引起結(jié)束處理程序的try塊中的過(guò)早退出，因?yàn)槌绦虻男阅軙?huì)受到影響.

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

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

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

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

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

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

========================
修改代碼：（返回值：5，沒(méi)有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語(yǔ)句，它首先生成一個(gè)局部展開(kāi)來(lái)執(zhí)行finally塊中的內(nèi)容.
這一次，在finally塊中的代碼執(zhí)行之后，在ReturnValue標(biāo)號(hào)之后的代碼將執(zhí)行，因?yàn)樵趖ry塊和finally塊中都沒(méi)有返回發(fā)生.
這里的代碼使函數(shù)返回5,而且，由于中斷了從try塊到finally塊的自然流程，可能要蒙受很大的性能損失（取決于運(yùn)行程序的CPU）

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

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

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

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

從try塊進(jìn)入finally塊的正?？刂屏?

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

第三種情況，全局展開(kāi)（globalunwind），在發(fā)生的時(shí)候沒(méi)有明顯的標(biāo)識(shí)，我們?cè)诒菊虑懊鍲unc_SEHTerminate函數(shù)中已經(jīng)見(jiàn)到.在Func_SEHTerminate的try塊中，有一個(gè)對(duì)TermHappenSomeError函數(shù)的調(diào)用。TermHappenSomeError函數(shù)會(huì)引起一個(gè)內(nèi)存訪問(wèn)違規(guī)（memory access violation），一個(gè)全局展開(kāi)會(huì)使Func_SEHTerminate函數(shù)的finally塊執(zhí)行.

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

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

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

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

•提高程序的可讀性。

•使代碼更容易維護(hù)。

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

異常處理程序

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

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

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

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

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

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

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

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

EXCEPTION_EXECUTE_HANDLER

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

即，我感覺(jué)這個(gè)異常可能在某個(gè)時(shí)候發(fā)生，我已編寫(xiě)了代碼來(lái)處理這個(gè)問(wèn)題，現(xiàn)在我想執(zhí)行這個(gè)代碼”

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

第二種是允許從一個(gè)類(lèi)型化指針(typed pointer)轉(zhuǎn)變成無(wú)類(lèi)型指針(untyped pointer)，所以帶有const void* 指針的catch子句能捕獲任何類(lèi)型的指針類(lèi)型異常:
catch (const void*) ... //可以捕獲所有指針異常
另外，你還可以用catch(...)來(lái)捕獲所有異常，注意是三個(gè)點(diǎn).
傳遞參數(shù)和傳遞異常間最后一點(diǎn)差別是catch子句匹配順序總是取決于它們?cè)诔绦蛑谐霈F(xiàn)的順序.
因此一個(gè)派生類(lèi)異?？赡鼙惶幚砥浠?lèi)異常的catch子句捕獲，這叫異常截獲，一般的編譯器會(huì)有警告.

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類(lèi)型的異常會(huì)先被截獲。
{
   b.print();
}
catch(A& a)
{
   a.print() ;
}

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

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

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

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

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

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

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

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

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

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

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

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