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

時間  2019-11-19
標籤 c++ 異常 處理 try catch throw finally 用法 欄目 C&C++ 简体版
原文   原文鏈接
  • 寫在前面

　　所謂異常處理，即讓一個程序運行時遇到本身沒法處理的錯誤時拋出一個異常，但願調用者能夠發現處理問題.html

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

　　也許咱們已經使用過異常，可是你習慣使用異常了嗎？c++

　　如今不少軟件都是n*365*24小時運行，軟件的健壯性相當重要. git

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

　　C++標準異常：程序員

 　　也許你很高興看到錯誤以後的Heap/Stack中對象被釋放，但是若是沒有呢？編程

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

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

　　 <使用異常規格編程> <構造和析構中的異常拋出> <使用析構函數防止資源泄漏>,以及深刻一點的<拋出一個異常的行爲>.安全

　　SEH異常：微信

　　　　我要問你你是一個WIN32程序員嗎？若是不是，那麼也許你真的不須要看.

　　　　SEH是Windows的結構化異常，每個WIN32程序員都應該要掌握它.

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

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

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

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

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

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

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

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

1. 使用構造函數防止資源Leak（More effective C++ #10）

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

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

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

5. 瞭解異常處理形成的系統開銷 （More effective C++ #15）

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

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

  • C++異常 C++引入異常的緣由

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

寫出一個具備你但願的行爲的構造函數和析構函數也變的困難（不可預測），固然最危險的也許是咱們寫出的東東狗屁了，或者是速度變慢了.

大多數的程序員知道Howto use exception 來處理咱們的代碼，但是不少人並非很重視異常的處理（國外的不少Code卻是處理的很好，Java的Exception機制很不錯）.

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

在異常被throw後，沒有一個方法可以作到使軟件的行爲具備可預測性和可靠性

對C程序來講，使用Error Code就能夠了，爲何還要引入異常？由於異常不能被忽略.

若是一個函數經過設置一個狀態變量或返回錯誤代碼來表示一個異常狀態，沒有辦法保證函數調用者將必定檢測變量或測試錯誤代碼.

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

在C程序中，咱們能夠用int setjmp( jmp_buf env );和 void longjmp( jmp_buf env, int value );

這2個函數來完成和異常處理相識的功能，可是MSDN中介紹了在C++中使用longjmp來調整stack時不可以對局部的對象調用析構函數，

可是對C++程序來講，析構函數是重要的（我就通常都把對象的Delete放在析構函數中）.

因此咱們須要一個方法：

　　①可以通知異常狀態，又不能忽略這個通知.

　　②而且Searching the stack以便找到異常代碼時.

　　③還要確保局部對象的析構函數被Call.

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

有的地方只有用異常才能解決問題，好比說，在當前上下文環境中，沒法捕捉或肯定的錯誤類型，咱們就得用一個異常拋出到更大的上下文環境當中去.

還有，異常處理的使用呢，可使出錯處理程序與「一般」代碼分離開來，使代碼更簡潔更靈活.

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

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

異常能夠由一個肯定類或派生類的對象產生。C++能釋放堆棧，並可清除堆棧中全部的對象.

C++的異常和pascal不一樣，是要程序員本身去實現的，編譯器不會作過多的動做.

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

throw ExceptionClass(「my throw「);

例句中，ExceptionClass是一個類，它的構造函數以一個字符串作爲參數.

也就是說，在throw的時候，C++的編譯器先構造一個ExceptionClass的對象，讓它做爲throw的值拋出去,同時，程序返回，調用析構.

看下面這個程序：

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

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

這是輸出信息：

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

不過通常來講咱們可能更習慣於把會產生異常的語句和要throw的異常類分紅不一樣的類來寫，下面的代碼能夠是咱們更願意書寫的.

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

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

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

輸出Message：

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

使用異常規格編程

若是咱們調用別人的函數，裏面有異常拋出，用去查看它的源代碼去看看都有什麼異常拋出嗎？這樣就會很煩瑣.

比較好的解決辦法，是編寫帶有異常拋出的函數時，採用異常規格說明，使咱們看到函數聲明就知道有哪些異常出現。

異常規格說明大致上爲如下格式：

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

全部異常類都在函數末尾的throw()的括號中得以說明了，這樣，對於函數調用者來講，是一清二楚的。

注意下面一種形式：

void ExceptionFunction(argument…) throw() 

代表沒有任何異常拋出.

而正常的void ExceptionFunction(argument…)則表示：可能拋出任何一種異常，固然，也可能沒有異常，意義是最普遍的.

異常捕獲以後，能夠再次拋出，就用一個不帶任何參數的throw語句就能夠了.

構造和析構中的異常拋出

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

先看個程序，假如我在構造函數的地方拋出異常，這個類的析構會被調用嗎？可若是不調用，那類裏的東西豈不是不能被釋放了？

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

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

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

結果爲：

ExceptionClass1()
throw a exception

在這兩句輸出之間，咱們已經給S分配了內存，但內存沒有被釋放（由於它是在析構函數中釋放的）.

應該說這符合實際現象，由於對象沒有完整構造.

爲了不這種狀況，我想你也許會說：應避免對象經過自己的構造函數涉及到異常拋出.

即：既不在構造函數中出現異常拋出，也不該在構造函數調用的一切東西中出現異常拋出.

可是在C++中能夠在構造函數中拋出異常，經典的解決方案是使用STL的標準類auto_ptr.

其實咱們也能夠這樣作來實現：

　　在類中增長一個 Init()以及 UnInit();成員函數用於進行容易產生錯誤的資源分配工做，而真正的構造函數中先將全部成員置爲NULL，而後調用 Init();

並判斷其返回值/或者捕捉 Init()拋出的異常，若是Init();失敗了，則在構造函數中調用 UnInit(); 並設置一個標誌位代表構造失敗.

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

那麼，在析構函數中的狀況呢？

咱們已經知道，異常拋出以後，就要調用自己的析構函數，若是這析構函數中還有異常拋出的話，則已存在的異常還沒有被捕獲，會致使異常捕捉不到.

標準C++異常類
C++有本身的標準的異常類.

① 一個基類：
exception 是全部C++異常的基類.

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

② 下面派生了兩個異常類：

logic_erro        報告程序的邏輯錯誤，可在程序執行前被檢測到 .

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

以上兩個又分別有本身的派生類：

③  由logic_erro派生的異常類

domain_error            報告違反了前置條件

invalid_argument        指出函數的一個無效參數

length_error  　　　　　　指出有一個產生超過 NPOS 長度的對象的企圖（ NPOS 爲 size_t 的最大可表現值

out_of_range  　　　　　　報告參數越界

bad_cast                在運行時類型識別中有一個無效的 dynamic_cast 表達式

bad_typeid  　　　　　　　報告在表達式 typeid( *p) 中有一個空指針P

④  由runtime_error派生的異常

range_error　　　　  報告違反了後置條件

overflow_error  　　報告一個算術溢出

bad_alloc           報告一個存儲分配錯誤

使用析構函數防止資源泄漏

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

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

天天收容所創建一個文件，包含當天它所管理的收容動物的資料信息，你的工做是寫一個程序讀出這些文件而後對每一個收容動物進行適當的處理（appropriate processing）.

完成這個程序一個合理的方法是定義一個抽象類，ALA（"Adorable Little Animal")，而後爲小狗和小貓創建派生類.

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

class  ALA  {

public :

　 virtual  void  processAdoption()  =  0;

　 ...

};

class  Puppy :  public  ALA  {

public :

　 virtual  void  processAdoption();

　 ...

};

class  Kitten :  public  ALA  {

public :

　 virtual  void  processAdoption();

　 ...

};

你須要一個函數從文件中讀信息，而後根據文件中的信息產生一個puppy（小狗）對象或者kitten(小貓)對象.

這個工做很是適合於虛擬構造器（virtual constructor），在條款25詳細描述了這種函數.

爲了完成咱們的目標，咱們這樣聲明函數：

// 從s中讀動物信息, 而後返回一個指針

// 指向新創建的某種類型對象

ALA  *  readALA( istream & s);

你的程序的關鍵部分就是這個函數，以下所示：

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

這個函數循環遍歷dataSource內的信息，處理它所遇到的每一個項目.

惟一要記住的一點是在每次循環結尾處刪除ps.

這是必須的，由於每次調用readALA都創建一個堆對象.若是不刪除對象，循環將產生資源泄漏。

如今考慮一下，若是pa->processAdoption拋出了一個異常，將會發生什麼？

processAdoptions沒有捕獲異常，因此異常將傳遞給processAdoptions的調用者.

轉遞中，processAdoptions函數中的調用pa->processAdoption語句後的全部語句都被跳過，這就是說pa沒有被刪除.

結果，任什麼時候候pa->processAdoption拋出一個異常都會致使processAdoptions內存泄漏.

很容易堵塞泄漏.

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

可是你必須用try和catch對你的代碼進行小改動.

更重要的是你必須寫雙份清除代碼，一個爲正常的運行準備，一個爲異常發生時準備.

在這種狀況下，必須寫兩個delete代碼.

象其它重複代碼同樣，這種代碼寫起來使人心煩又難於維護，並且它看上去好像存在着問題.

不論咱們是讓processAdoptions正常返回仍是拋出異常，咱們都須要刪除pa，因此爲何咱們必需要在多個地方編寫刪除代碼呢？

咱們能夠把總被執行的清除代碼放入processAdoptions函數內的局部對象的析構函數裏，這樣能夠避免重複書寫清除代碼.

由於當函數返回時局部對象老是被釋放，不管函數是如何退出的.

（僅有一種例外就是當你調用longjmp時。Longjmp的這個缺點是C++率先支持異常處理的主要緣由）

具體方法是用一個對象代替指針pa，這個對象的行爲與指針類似。當pointer-like（類指針）對象被釋放時，咱們能讓它的析構函數調用delete.

替代指針的對象被稱爲smart pointers（靈巧指針），下面有解釋，你能使得pointer-like對象很是靈巧.

在這裏，咱們用不着這麼聰明的指針，咱們只須要一個pointer-lik對象，當它離開生存空間時知道刪除它指向的對象.

寫出這樣一個類並不困難，可是咱們不須要本身去寫。標準C++庫函數包含一個類模板，叫作auto_ptr，這正是咱們想要的.

每個auto_ptr類的構造函數裏，讓一個指針指向一個堆對象（heap object），而且在它的析構函數裏刪除這個對象.

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

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

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

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

可是它背後所蘊含的原理應該是清楚的：用auto_ptr對象代替raw指針，你將再也不爲堆對象不能被刪除而擔憂，即便在拋出異常時，對象也能被及時刪除.

(由於auto_ptr的析構函數使用的是單對象形式的delete，因此auto_ptr不能用於指向對象數組的指針.

若是想讓auto_ptr相似於一個數組模板，你必須本身寫一個。在這種狀況下，用vector代替array可能更好)

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

使用auto_ptr對象代替raw指針，processAdoptions以下所示：

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

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

第一， pa被聲明爲一個auto_ptr<ALA>對象，而不是一個raw ALA*指針.

第二， 在循環的結尾沒有delete語句.

其他部分都同樣，由於除了析構的方式，auto_ptr對象的行爲就象一個普通的指針。是否是很容易.

隱藏在auto_ptr後的思想是：

　　用一個對象存儲須要被自動釋放的資源，而後依靠對象的析構函數來釋放資源，這種思想不僅是能夠運用在指針上，還能用在其它資源的分配和釋放上.

想一下這樣一個在GUI程序中的函數，它須要創建一個window來顯式一些信息：

// 這個函數會發生資源泄漏，若是一個異常拋出

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

不少window系統有C－like接口，使用象like createWindow 和 destroyWindow函數來獲取和釋放window資源.

若是在w對應的window中顯示信息時，一個異常被拋出，w所對應的window將被丟失，就象其它動態分配的資源同樣.

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

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

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

這個能力對於使用WindowHandle對象很是重要，由於這意味着你能在任何地方象使用raw WINDOW_HANDLE同樣來使用WindowHandle.

（參見More effective C++條款5 ，瞭解爲何你應該謹慎使用隱式類型轉換操做）

經過給出的WindowHandle類，咱們可以重寫displayInfo函數，以下所示：

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

即便一個異常在displayInfo內被拋出，被createWindow 創建的window也能被釋放.

資源應該被封裝在一個對象裏，遵循這個規則，你一般就能避免在存在異常環境裏發生資源泄漏.

可是若是你正在分配資源時一個異常被拋出，會發生什麼狀況呢？

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

還有若是這樣的資源正在被釋放時，一個異常被拋出，又會發生什麼狀況呢？

構造函數和析構函數須要特殊的技術.

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

拋出一個異常的行爲

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

條款12：理解「拋出一個異常」與「傳遞一個參數」或「調用一個虛函數」間的差別

從語法上看，在函數裏聲明參數與在catch子句中聲明參數幾乎沒有什麼差異：

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

你所以可能會認爲用throw拋出一個異常到catch子句中與經過函數調用傳遞一個參數二者基本相同.

這裏面確有一些相同點，可是他們也存在着巨大的差別.

讓咱們先從相同點談起.

你傳遞函數參數與異常的途徑能夠是傳值、傳遞引用或傳遞指針，這是相同的.

可是當你傳遞參數和異常時，系統所要完成的操做過程則是徹底不一樣的.

產生這個差別的緣由是：你調用函數時，程序的控制權最終還會返回到函數的調用處，可是當你拋出一個異常時，控制權永遠不會回到拋出異常的地方。

有這樣一個函數，參數類型是Widget，並拋出一個Widget類型的異常：

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

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

這與拋出localWidget異常有很大不一樣.

不論經過傳值捕獲異常仍是經過引用捕獲（不能經過指針捕獲這個異常，由於類型不匹配）都將進行lcalWidget的拷貝操做，也就說傳遞到catch子句中的是localWidget的拷貝.

必須這麼作，由於當localWidget離開了生存空間後，其析構函數將被調用.

若是把localWidget自己（而不是它的拷貝）傳遞給catch子句，這個子句接收到的只是一個被析構了的Widget，一個Widget的「屍體」.

這是沒法使用的。所以C++規範要求被作爲異常拋出的對象必須被複制.

即便被拋出的對象不會被釋放，也會進行拷貝操做.

例如若是passAndThrowWidget函數聲明localWidget爲靜態變量（static），

void  passAndThrowWidget()
{
      static  Widget  localWidget;         // 如今是靜態變量（static） 一直存在至程序結束
      cin  >>  localWidget;                // 象之前那樣運行
      throw  localWidget;                 // 仍將對localWidget進行拷貝操做
}

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

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

對異常對象進行強制複製拷貝，這個限制有助於咱們理解參數傳遞與拋出異常的第二個差別：拋出異常運行速度比參數傳遞要慢.

當異常對象被拷貝時，拷貝操做是由對象的拷貝構造函數完成的.

該拷貝構造函數是對象的靜態類型（static type）所對應類的拷貝構造函數，而不是對象的動態類型（dynamic type）對應類的拷貝構造函數.

好比如下這通過少量修改的passAndThrowWidget：

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

這裏拋出的異常對象是Widget，即便rw引用的是一個SpecialWidget.

由於rw的靜態類型（static type）是Widget，而不是SpecialWidget.

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

這種行爲可能與你所期待的不同，可是這與在其餘狀況下C++中拷貝構造函數的行爲是一致的.

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

異常是其它對象的拷貝，這個事實影響到你如何在catch塊中再拋出一個異常.

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

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

這兩個catch塊的差異在於第一個catch塊中從新拋出的是當前捕獲的異常，而第二個catch塊中從新拋出的是當前捕獲異常的一個新的拷貝.

若是忽略生成額外拷貝的系統開銷，這兩種方法還有差別麼？
固然有。第一個塊中從新拋出的是當前異常（current exception）,不管它是什麼類型.

特別是若是這個異常開始就是作爲SpecialWidget類型拋出的，那麼第一個塊中傳遞出去的仍是SpecialWidget異常，即便w的靜態類型（static type）是Widget.

這是由於從新拋出異常時沒有進行拷貝操做.

第二個catch塊從新拋出的是新異常，類型老是Widget，由於w的靜態類型（static type）是Widget.

通常來講，你應該用throw來從新拋出當前的異常，由於這樣不會改變被傳遞出去的異常類型，並且更有效率，由於不用生成一個新拷貝.

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

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

不過我想你的編譯器很難這麼作，由於程序中不多發生異常，因此編譯器廠商不會在這方面花大量的精力）

讓咱們測試一下下面這三種用來捕獲Widget異常的catch子句，異常是作爲passAndThrowWidgetp拋出的：

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

咱們馬上注意到了傳遞參數與傳遞異常的另外一個差別.

一個被異常拋出的對象（剛纔解釋過，老是一個臨時對象）能夠經過普通的引用捕獲.

它不須要經過指向const對象的引用（reference-to-const）捕獲.

在函數調用中不容許轉遞一個臨時對象到一個非const引用類型的參數裏（參見條款19），可是在異常中卻被容許.

讓咱們先無論這個差別，回到異常對象拷貝的測試上來.

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

一樣咱們經過傳值的方式傳遞一個異常時，也是這麼作的。當咱們這樣聲明一個catch子句時:

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

會創建兩個被拋出對象的拷貝，一個是全部異常都必須創建的臨時對象，第二個是把臨時對象拷貝進w中.

一樣，當咱們經過引用捕獲異常時:

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

這仍舊會創建一個被拋出對象的拷貝：拷貝是一個臨時對象.

相反當咱們經過引用傳遞函數參數時，沒有進行對象拷貝.

當拋出一個異常時，系統構造的（之後會析構掉）被拋出對象的拷貝數比以相同對象作爲參數傳遞給函數時構造的拷貝數要多一個.

咱們尚未討論經過指針拋出異常的狀況，不過經過指針拋出異常與經過指針傳遞參數是相同的.

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

你不能認爲拋出的指針是一個指向局部對象的指針，由於當異常離開局部變量的生存空間時，該局部變量已經被釋放.

Catch子句將得到一個指向已經不存在的對象的指針。這種行爲在設計時應該予以免.

對象從函數的調用處傳遞到函數參數裏與從異常拋出點傳遞到catch子句裏所採用的方法不一樣，

這只是參數傳遞與異常傳遞的區別的一個方面，第二個差別是在函數調用者或拋出異常者與被調用者或異常捕獲者之間的類型匹配的過程不一樣.

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

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

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

int i;
double sqrtOfi = sqrt(i);

毫無疑問，C++容許進行從int到double的隱式類型轉換，因此在sqrt的調用中，i 被悄悄地轉變爲double類型，而且其返回值也是double.

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

見下面的代碼：

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

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

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

所以若是要想捕獲int異常，必須使用帶有int或int&參數的catch子句.

不過在catch子句中進行異常匹配時能夠進行兩種類型轉換.

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

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

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

捕獲runtime_errors異常的Catch子句能夠捕獲range_error類型和overflow_error類型的異常，

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

這種派生類與基類（inheritance_based）間的異常類型轉換能夠做用於數值、引用以及指針上：

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

第二種是容許從一個類型化指針（typed pointer）轉變成無類型指針（untyped pointer），

因此帶有const void* 指針的catch子句能捕獲任何類型的指針類型異常：

catch (const void*) ...                 file://捕獲任何指針類型異常
 
傳遞參數和傳遞異常間最後一點差異是catch子句匹配順序老是取決於它們在程序中出現的順序.

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

例如：

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

與上面這種行爲相反，當你調用一個虛擬函數時，被調用的函數位於與發出函數調用的對象的動態類型（dynamic type）最相近的類裏.

你能夠這樣說虛擬函數採用最優適合法，而異常處理採用的是最早適合法.

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

（由於這樣的代碼在C++裏一般是不合法的）

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

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

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

綜上所述，把一個對象傳遞給函數或一個對象調用虛擬函數與把一個對象作爲異常拋出，這之間有三個主要區別.

第1、異常對象在傳遞時總被進行拷貝；當經過傳值方式捕獲時，異常對象被拷貝了兩次.

對象作爲參數傳遞給函數時不須要被拷貝.

第2、對象作爲異常被拋出與作爲參數傳遞給函數相比，前者類型轉換比後者要少（前者只有兩種轉換形式）.

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

當一個對象調用一個虛擬函數時，被選擇的函數位於與對象類型匹配最佳的類裏，即便該類不是在源代碼的最前頭.

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

其實靈巧指針的做用很大，對咱們來講垃圾回收，ATL等都會使用到它.

在More effective 的條款後面特地增長這個節點，不只是想介紹它在異常處理方面的做用，還但願對編寫別的類型代碼的時候能夠有所幫助.

smart pointer（靈巧指針）其實並非一個指針,實際上是某種形式的類.

不過它的特長就是模仿C/C++中的指針，因此就叫pointer 了.

因此但願你們必定要記住兩點：smart pointer是一個類而非指針，但特長是模仿指針.

那怎麼作到像指針的呢？

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

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

其次須要模仿指針主要的兩個運算符->和*，那就須要進行運算符重載.

詳細的實現：

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

這只是一個大概的印象，不少東西是能夠更改的.

好比能夠去掉或加上一些const ，這都須要根據具體的應用環境而定.

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

而因爲smart pointer是一個類，在構造函數、析構函數中均可以經過恰當的編程達到一些不錯的效果.
舉例：
好比C++標準庫裏的std::auto_ptr 就是應用很廣的一個例子.

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

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

關於auto_ptr 的使用能夠找到不少的列子，這裏不在舉了.

它的主要優勢是不用 delete ，能夠自動回收已經被分配的空間，由此能夠避免資源泄露的問題.

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

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

而且即便在產生異常的狀況下， auto_ptr 也能正確地回收資源.

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

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

針對不一樣的smart pointer ，有不一樣的注意事項。好比auto_ptr ，就不能把它用在標準容器裏，由於它只在內存中保留一份實例.

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

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

SmartPtr p; 
if(p==0) 
if(!p) 
if(p) 
很顯然， p 不是一個真正的指針，這麼作可能出錯.

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

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

若是堅持非要用上面的形式， 那也是能夠的,咱們就加上operator void* ()試試： 

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

這種方法在basic_ios 中就使用過了。這裏也能夠更靈活地處理，好比類自己須要operator void*()這樣地操做，

那麼上面這種方法就不靈了。但咱們還有重載operator !()等等方法來實現.
總結smart pointer的實質： 
smart pointer 的實質就是一個外殼，一層包裝。正是多了這層包裝，咱們能夠作出許多普通指針沒法完成的事，好比前面資源自動回收，或者自動進行引用記數，好比ATL 中CComPtr 和 CComQIPtr 這兩個COM 接口指針類.

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

WIN結構化異常

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

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

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

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

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

必定要記得在背後的事情：在使用SEH的時候，編譯程序和操做系統直接參與了程序代碼的執行。

Win32異常事件的理解

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

Exception（異常處理） 分紅軟件和硬件exception2種.如：一個無效的參數或者被0除都會引發軟件exception，而訪問一個還沒有commit的頁會引發硬件exception.

發生異常的時候，執行流程終止，同時控制權轉交給操做系統，OS會用上下文（CONTEXT）結構把當前的進程狀態保存下來，而後就開始search 一個能處理exception的組件，search order以下：

1. 首先檢查是否有一個調試程序與發生exception的進程聯繫在一塊兒，推算這個調試程序是否有能力處理

2. 如上面不能完成，操做系統就在發生exception event的線程中search exception event handler

3. search與進程關聯在一塊兒的調試程序

4. 系統執行本身的exception event handler code and terminate process

結束處理程序

利用SEH，你能夠徹底不用考慮代碼裏是否是有錯誤，這樣就把主要的工做同錯誤處理分離開來.

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

微軟在Windows中引入SEH的主要動機是爲了便於操做系統自己的開發.

操做系統的開發人員使用SEH，使得系統更增強壯.咱們也可使用SEH，使咱們的本身的程序更增強壯.

使用SEH所形成的負擔主要由編譯程序來承擔，而不是由操做系統承擔.

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

編譯程序必須產生一些表（table）來支持處理SEH的數據結構.

編譯程序還必須提供回調（callback）函數，操做系統能夠調用這些函數，保證異常塊被處理.

編譯程序還要負責準備棧結構和其餘內部信息，供操做系統使用和參考.

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

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

幸好咱們能夠沒必要考慮編譯程序的實現細節，而只使用編譯程序的SEH功能.

（其實大多數編譯程序廠商都採用微軟建議的語法）

 

結束處理程序代碼初步

一個結束處理程序可以確保去調用和執行一個代碼塊（結束處理程序，termination handler），

而無論另一段代碼（保護體， guarded body）是如何退出的。結束處理程序的語法結構以下： __try
{
   file://保護塊
}
__finally
{
  file://結束處理程序
}
在上面的代碼段中，操做系統和編譯程序共同來確保結束處理程序中的__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;
}

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

這個return語句告訴編譯程序在這裏要退出這個函數並返回dwTemp變量的內容，如今這個變量的值是5.

可是，若是這個return語句被執行，該線程將不會釋放信標，其餘線程也就不能再得到對信標的控制.

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

經過使用結束處理程序，能夠避免return語句的過早執行.

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

要保證finally塊中的代碼在try塊中的return語句退出以前執行.

在程序中，將ReleaseSemaphore的調用放在結束處理程序塊中，保證信標總會被釋放.

 

這樣就不會形成一個線程一直佔有信標，不然將意味着全部其餘等待信標的線程永遠不會被分配CPU時間.

在finally塊中的代碼執行以後，函數實際上就返回.

任何出如今finally塊之下的代碼將再也不執行，由於函數已在try塊中返回,因此這個函數的返回值是5，而不是10.

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

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

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

編譯程序而後再生成代碼來執行finally塊中包含的指令，這稱爲局部展開.

更特殊的狀況是，因爲try塊中存在過早退出的代碼，從而產生局部展開，致使系統執行finally塊中的內容.

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

能夠看到，要完成這些事情，編譯程序必須生成附加的代碼，系統要執行額外的工做.

在不一樣的CPU上，結束處理所須要的步驟也不一樣.

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

在編寫代碼時，就應該避免引發結束處理程序的try塊中的過早退出，由於程序的性能會受到影響.

後面，將討論__leave關鍵字，它有助於避免編寫引發局部展開的代碼.

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

若是狀況是正常的，明確地檢查這些狀況，比起依賴操做系統和編譯程序的SEH功能來捕捉常見的事情要更有效.

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

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

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

========================

修改代碼：（返回值：5，沒有Leak，性能消耗：中）

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

代碼中，當編譯程序看到try塊中的goto語句，它首先生成一個局部展開來執行finally塊中的內容.

這一次，在finally塊中的代碼執行以後，在ReturnValue標號以後的代碼將執行，由於在try塊和finally塊中都沒有返回發生.

這裏的代碼使函數返回5,並且，因爲中斷了從try塊到finally塊的天然流程，可能要蒙受很大的性能損失（取決於運行程序的CPU）

 

 

寫上面的代碼是初步的，如今來看結束處理程序在咱們代碼裏面的真正的價值：
看代碼：（信號燈被正常釋放，reserve的一頁內存沒有被Free，安全性：安全）

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

 

finally塊的總結性說明

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

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

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

第三種狀況，全局展開（globalunwind），在發生的時候沒有明顯的標識，咱們在本章前面Func_SEHTerminate函數中已經見到.在Func_SEHTerminate的try塊中，有一個對TermHappenSomeError函數的調用。TermHappenSomeError函數會引發一個內存訪問違規（memory access violation），一個全局展開會使Func_SEHTerminate函數的finally塊執行.

因爲以上三種狀況中某一種的結果而致使finally塊中的代碼開始執行。爲了肯定是哪種狀況引發finally塊執行，能夠調用內部函數AbnormalTermination：這個內部函數只在finally塊中調用，返回一個Boolean值.指出與finally塊相結合的try塊是否過早退出。換句話說，若是控制流離開try塊並天然進入finally塊，AbnormalTermination將返回FALSE。若是控制流非正常退出try塊—一般因爲goto、return、break或continue語句引發的局部展開，或因爲內存訪問違規或其餘異常引發的全局展開—對AbnormalTermination的調用將返回TRUE。沒有辦法區別finally塊的執行是因爲全局展開仍是因爲局部展開.

但這一般不會成爲問題，由於能夠避免編寫執行局部展開的代碼.（注意內部函數是編譯程序識別的一種特殊函數。編譯程序爲內部函數產生內聯（inline）代碼而不是生成調用函數的代碼。例如，memcpy是一個內部函數（若是指定/Oi編譯程序開關）。當編譯程序看到一個對memcpy的調用，它直接將memcpy的代碼插入調用memcpy的函數中，而不是生成一個對memcpy函數的調用。其做用是代碼的長度增長了，但執行速度加快了。

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

•簡化錯誤處理，因全部的清理工做都在一個位置而且保證被執行。

•提升程序的可讀性。

•使代碼更容易維護。

•若是使用得當，具備最小的系統開銷。

異常處理程序

異常是咱們不但願有的事件。在編寫程序的時候，程序員不會想去存取一個無效的內存地址或用0來除一個數值。不過，這樣的錯誤仍是經常會發生的。CPU負責捕捉無效內存訪問和用0除一個數值這種錯誤，並相應引起一個異常做爲對這些錯誤的反應。CPU引起的異常，就是所謂的硬件異常（hardwareexception）。在本章的後面，咱們還會看到操做系統和應用程序也能夠引起相應的異常，稱爲軟件異常（softwareexception）。

當出現一個硬件或軟件異常時，操做系統嚮應用程序提供機會來考察是什麼類型的異常被引起，並可以讓應用程序本身來處理異常。下面就是異常處理程序的語法：

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

注意__ 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塊以後的第一條指令恢復。

  • c++異常參數傳遞
從語法上看，在函數裏聲明參數與在catch子句中聲明參數是同樣的，catch裏的參數能夠是值類型，引用類型，指針類型.例如：
try
{
      .....
}
catch( A  a)
{
}
catch(B & b)
{
}
catch( C *  c)
{
}
儘管表面是它們是同樣的，可是編譯器對兩者的處理卻又很大的不一樣.
調用函數時，程序的控制權最終還會返回到函數的調用處，可是拋出一個異常時，控制權永遠不會回到拋出異常的地方.
class  A;
void  func_throw()
{
      A  a;
      throw  a;   //拋出的是a的拷貝，拷貝到一個臨時對象裏
}
try
{
      func_throw();
}
catch( A  a)   //臨時對象的拷貝
{
}
當咱們拋出一個異常對象時，拋出的是這個異常對象的拷貝。當異常對象被拷貝時，拷貝操做是由對象的拷貝構造函數完成的.
該拷貝構造函數是對象的靜態類型(static type)所對應類的拷貝構造函數，而不是對象的動態類型(dynamic type)對應類的拷貝構造函數。此時對象會丟失RTTI信息.
異常是其它對象的拷貝，這個事實影響到你如何在catch塊中再拋出一個異常。好比下面這兩個catch塊，乍一看好像同樣:
catch( A &  w)   // 捕獲異常
{
     　 // 處理異常
     　 throw;  // 從新拋出異常，讓它繼續傳遞
}
catch( A &  w)   // 捕獲Widget異常
{
     　 // 處理異常
     　 throw  w;  // 傳遞被捕獲異常的拷貝
}
  第一個塊中從新拋出的是當前異常(current exception),不管它是什麼類型。（有多是A的派生類）  
  第二個catch塊從新拋出的是新異常，失去了原來的類型信息.
  通常來講，你應該用throw來從新拋出當前的異常，由於這樣不會改變被傳遞出去的異常類型，並且更有效率，由於不用生成一個新拷貝.
看看如下這三種聲明:
catch (A w) ... // 經過傳值
catch (A& w) ... // 經過傳遞引用
catch (const A& w) ... //const引用
一個被異常拋出的對象(老是一個臨時對象)能夠經過普通的引用捕獲;它不須要經過指向const對象的引用(reference-to-const)捕獲.
在函數調用中不容許轉遞一個臨時對象到一個非const引用類型的參數裏，可是在異常中卻被容許.
回到異常對象拷貝上來,咱們知道，當用傳值的方式傳遞函數的參數，咱們製造了被傳遞對象的一個拷貝，並把這個拷貝存儲到函數的參數裏.
一樣咱們經過傳值的方式傳遞一個異常時，也是這麼作的當咱們這樣聲明一個catch子句時:
catch (A w) ... // 經過傳值捕獲
會創建兩個被拋出對象的拷貝，一個是全部異常都必須創建的臨時對象，第二個是把臨時對象拷貝進w中。實際上，編譯器會優化掉一個拷貝。一樣，當咱們經過引用捕獲異常時，
catch (A& w) ... // 經過引用捕獲
catch (const A& w) ... //const引用捕獲
這仍舊會創建一個被拋出對象的拷貝:拷貝是一個臨時對象。相反當咱們經過引用傳遞函數參數時，沒有進行對象拷貝.
話雖如此，可是不是全部編譯器都如此,VS200就表現很詭異.
經過指針拋出異常與經過指針傳遞參數是相同的.
不論哪一種方法都是一個指針的拷貝被傳遞,你不能認爲拋出的指針是一個指向局部對象的指針，由於當異常離開局部變量的生存空間時，該局部變量已經被釋放.
Catch子句將得到一個指向已經不存在的對象的指針。這種行爲在設計時應該予以免.
另一個重要的差別是在函數調用者或拋出異常者與被調用者或異常捕獲者之間的類型匹配的過程不一樣.
在函數傳遞參數時，若是參數不匹配，那麼編譯器會嘗試一個類型轉換，若是存在的話。而對於異常處理的話，則徹底不是這樣。見一下的例子：
void  func_throw()
{
      CString  a;
      throw  a;   //拋出的是a的拷貝，拷貝到一個臨時對象裏
}
try
{
      func_throw();
}
catch( const  char * s)
{
     
}
拋出的是CString，若是用const char*來捕獲的話，是捕獲不到這個異常的.
儘管如此，在catch子句中進行異常匹配時能夠進行兩種類型轉換.第一種是基類與派生類的轉換，一個用來捕獲基類的catch子句也能夠處理派生類類型的異常.
反過來，用來捕獲派生類的沒法捕獲基類的異常.

第二種是容許從一個類型化指針(typed pointer)轉變成無類型指針(untyped pointer)，因此帶有const void* 指針的catch子句能捕獲任何類型的指針類型異常:
catch (const void*) ... //能夠捕獲全部指針異常
另外，你還能夠用catch(...)來捕獲全部異常，注意是三個點.
傳遞參數和傳遞異常間最後一點差異是catch子句匹配順序老是取決於它們在程序中出現的順序.
所以一個派生類異常可能被處理其基類異常的catch子句捕獲，這叫異常截獲，通常的編譯器會有警告.
class  A
{
public :
      A()
      {
            cout  <<  "class A creates"  <<  endl;
      }
      void  print()
      {
            cout  <<  "A"  <<  endl;
      }
      ~ A()
      {
            cout  <<  "class A destruct"  <<  endl;
      }
};
class B :  public  A
{
public :
     B()
      {
            cout  <<  "class B create"  <<  endl;
      }
      void  print()
      {
            cout  <<  "B"  <<  endl;
      }
      ~B()
      {
            cout  <<  "class B destruct"  <<  endl;
      }
};
void  func()
{
     B b;
      throw b;
}
try
{
      func();
}
catch(B & b)   //必須將B放前面，若是把A放前面，B放後面，那麼B類型的異常會先被截獲。
{
     b . print();
}
catch( A &  a)
{
      a . print() ;
}
 
 
相反的是，當你調用一個虛擬函數時，被調用的函數位於與發出函數調用的對象的動態類型(dynamic type)最相近的類裏.
 
你能夠這樣說虛擬函數匹配採用最優匹配法，而異常處理匹配採用的是最早匹配法.

附：
異常的描述

函數和函數可能拋出的異常集合做爲函數聲明的一部分是有價值的，例如

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

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

若是f函數違反了這個規定，拋出了x2,x3以外的異常,例如x4,那麼當函數f拋出x4異常時，

會轉換爲一個std::unexpected()調用，默認是調用std::terminate(),一般是調用abort().

若是函數不帶異常描述，那麼假定他可能拋出任何異常,例如:

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

不帶任何異常的函數能夠用空表表示:

int  g()  throw();   // 不會拋出任何異常
 
  本文章部份內容參考hellodev的博客
 
轉載請註明出處:http://www.cnblogs.com/crazyacking/p/4951638.html ，侵權必究.

不過通常來講咱們可能更習慣於把會產生異常的語句和要throw的異常類分紅不一樣的類來寫，下面的代碼能夠是咱們更願意書寫的.

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

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

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

輸出Message：

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

使用異常規格編程

若是咱們調用別人的函數，裏面有異常拋出，用去查看它的源代碼去看看都有什麼異常拋出嗎？這樣就會很煩瑣.

比較好的解決辦法，是編寫帶有異常拋出的函數時，採用異常規格說明，使咱們看到函數聲明就知道有哪些異常出現。

異常規格說明大致上爲如下格式：

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

全部異常類都在函數末尾的throw()的括號中得以說明了，這樣，對於函數調用者來講，是一清二楚的。

注意下面一種形式：

void ExceptionFunction(argument…) throw() 

代表沒有任何異常拋出.

而正常的void ExceptionFunction(argument…)則表示：可能拋出任何一種異常，固然，也可能沒有異常，意義是最普遍的.

異常捕獲以後，能夠再次拋出，就用一個不帶任何參數的throw語句就能夠了.

構造和析構中的異常拋出

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

先看個程序，假如我在構造函數的地方拋出異常，這個類的析構會被調用嗎？可若是不調用，那類裏的東西豈不是不能被釋放了？

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

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

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

結果爲：

ExceptionClass1()
throw a exception

在這兩句輸出之間，咱們已經給S分配了內存，但內存沒有被釋放（由於它是在析構函數中釋放的）.

應該說這符合實際現象，由於對象沒有完整構造.

爲了不這種狀況，我想你也許會說：應避免對象經過自己的構造函數涉及到異常拋出.

即：既不在構造函數中出現異常拋出，也不該在構造函數調用的一切東西中出現異常拋出.

可是在C++中能夠在構造函數中拋出異常，經典的解決方案是使用STL的標準類auto_ptr.

其實咱們也能夠這樣作來實現：

　　在類中增長一個 Init()以及 UnInit();成員函數用於進行容易產生錯誤的資源分配工做，而真正的構造函數中先將全部成員置爲NULL，而後調用 Init();

並判斷其返回值/或者捕捉 Init()拋出的異常，若是Init();失敗了，則在構造函數中調用 UnInit(); 並設置一個標誌位代表構造失敗.

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

那麼，在析構函數中的狀況呢？

咱們已經知道，異常拋出以後，就要調用自己的析構函數，若是這析構函數中還有異常拋出的話，則已存在的異常還沒有被捕獲，會致使異常捕捉不到.

標準C++異常類
C++有本身的標準的異常類.

① 一個基類：
exception 是全部C++異常的基類.

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

② 下面派生了兩個異常類：

logic_erro        報告程序的邏輯錯誤，可在程序執行前被檢測到 .

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

以上兩個又分別有本身的派生類：

③  由logic_erro派生的異常類

domain_error            報告違反了前置條件

invalid_argument        指出函數的一個無效參數

length_error  　　　　　　指出有一個產生超過 NPOS 長度的對象的企圖（ NPOS 爲 size_t 的最大可表現值

out_of_range  　　　　　　報告參數越界

bad_cast                在運行時類型識別中有一個無效的 dynamic_cast 表達式

bad_typeid  　　　　　　　報告在表達式 typeid( *p) 中有一個空指針P

④  由runtime_error派生的異常

range_error　　　　  報告違反了後置條件

overflow_error  　　報告一個算術溢出

bad_alloc           報告一個存儲分配錯誤

使用析構函數防止資源泄漏

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

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

天天收容所創建一個文件，包含當天它所管理的收容動物的資料信息，你的工做是寫一個程序讀出這些文件而後對每一個收容動物進行適當的處理（appropriate processing）.

完成這個程序一個合理的方法是定義一個抽象類，ALA（"Adorable Little Animal")，而後爲小狗和小貓創建派生類.

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

class  ALA  {

public :

　 virtual  void  processAdoption()  =  0;

　 ...

};

class  Puppy :  public  ALA  {

public :

　 virtual  void  processAdoption();

　 ...

};

class  Kitten :  public  ALA  {

public :

　 virtual  void  processAdoption();

　 ...

};

你須要一個函數從文件中讀信息，而後根據文件中的信息產生一個puppy（小狗）對象或者kitten(小貓)對象.

這個工做很是適合於虛擬構造器（virtual constructor），在條款25詳細描述了這種函數.

爲了完成咱們的目標，咱們這樣聲明函數：

// 從s中讀動物信息, 而後返回一個指針

// 指向新創建的某種類型對象

ALA  *  readALA( istream & s);

你的程序的關鍵部分就是這個函數，以下所示：

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

這個函數循環遍歷dataSource內的信息，處理它所遇到的每一個項目.

惟一要記住的一點是在每次循環結尾處刪除ps.

這是必須的，由於每次調用readALA都創建一個堆對象.若是不刪除對象，循環將產生資源泄漏。

如今考慮一下，若是pa->processAdoption拋出了一個異常，將會發生什麼？

processAdoptions沒有捕獲異常，因此異常將傳遞給processAdoptions的調用者.

轉遞中，processAdoptions函數中的調用pa->processAdoption語句後的全部語句都被跳過，這就是說pa沒有被刪除.

結果，任什麼時候候pa->processAdoption拋出一個異常都會致使processAdoptions內存泄漏.

很容易堵塞泄漏.

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

可是你必須用try和catch對你的代碼進行小改動.

更重要的是你必須寫雙份清除代碼，一個爲正常的運行準備，一個爲異常發生時準備.

在這種狀況下，必須寫兩個delete代碼.

象其它重複代碼同樣，這種代碼寫起來使人心煩又難於維護，並且它看上去好像存在着問題.

不論咱們是讓processAdoptions正常返回仍是拋出異常，咱們都須要刪除pa，因此爲何咱們必需要在多個地方編寫刪除代碼呢？

咱們能夠把總被執行的清除代碼放入processAdoptions函數內的局部對象的析構函數裏，這樣能夠避免重複書寫清除代碼.

由於當函數返回時局部對象老是被釋放，不管函數是如何退出的.

（僅有一種例外就是當你調用longjmp時。Longjmp的這個缺點是C++率先支持異常處理的主要緣由）

具體方法是用一個對象代替指針pa，這個對象的行爲與指針類似。當pointer-like（類指針）對象被釋放時，咱們能讓它的析構函數調用delete.

替代指針的對象被稱爲smart pointers（靈巧指針），下面有解釋，你能使得pointer-like對象很是靈巧.

在這裏，咱們用不着這麼聰明的指針，咱們只須要一個pointer-lik對象，當它離開生存空間時知道刪除它指向的對象.

寫出這樣一個類並不困難，可是咱們不須要本身去寫。標準C++庫函數包含一個類模板，叫作auto_ptr，這正是咱們想要的.

每個auto_ptr類的構造函數裏，讓一個指針指向一個堆對象（heap object），而且在它的析構函數裏刪除這個對象.

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

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

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

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

可是它背後所蘊含的原理應該是清楚的：用auto_ptr對象代替raw指針，你將再也不爲堆對象不能被刪除而擔憂，即便在拋出異常時，對象也能被及時刪除.

(由於auto_ptr的析構函數使用的是單對象形式的delete，因此auto_ptr不能用於指向對象數組的指針.

若是想讓auto_ptr相似於一個數組模板，你必須本身寫一個。在這種狀況下，用vector代替array可能更好)

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

使用auto_ptr對象代替raw指針，processAdoptions以下所示：

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

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

第一， pa被聲明爲一個auto_ptr<ALA>對象，而不是一個raw ALA*指針.

第二， 在循環的結尾沒有delete語句.

其他部分都同樣，由於除了析構的方式，auto_ptr對象的行爲就象一個普通的指針。是否是很容易.

隱藏在auto_ptr後的思想是：

　　用一個對象存儲須要被自動釋放的資源，而後依靠對象的析構函數來釋放資源，這種思想不僅是能夠運用在指針上，還能用在其它資源的分配和釋放上.

想一下這樣一個在GUI程序中的函數，它須要創建一個window來顯式一些信息：

// 這個函數會發生資源泄漏，若是一個異常拋出

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

不少window系統有C－like接口，使用象like createWindow 和 destroyWindow函數來獲取和釋放window資源.

若是在w對應的window中顯示信息時，一個異常被拋出，w所對應的window將被丟失，就象其它動態分配的資源同樣.

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

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

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

這個能力對於使用WindowHandle對象很是重要，由於這意味着你能在任何地方象使用raw WINDOW_HANDLE同樣來使用WindowHandle.

（參見More effective C++條款5 ，瞭解爲何你應該謹慎使用隱式類型轉換操做）

經過給出的WindowHandle類，咱們可以重寫displayInfo函數，以下所示：

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

即便一個異常在displayInfo內被拋出，被createWindow 創建的window也能被釋放.

資源應該被封裝在一個對象裏，遵循這個規則，你一般就能避免在存在異常環境裏發生資源泄漏.

可是若是你正在分配資源時一個異常被拋出，會發生什麼狀況呢？

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

還有若是這樣的資源正在被釋放時，一個異常被拋出，又會發生什麼狀況呢？

構造函數和析構函數須要特殊的技術.

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

拋出一個異常的行爲

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

條款12：理解「拋出一個異常」與「傳遞一個參數」或「調用一個虛函數」間的差別

從語法上看，在函數裏聲明參數與在catch子句中聲明參數幾乎沒有什麼差異：

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

你所以可能會認爲用throw拋出一個異常到catch子句中與經過函數調用傳遞一個參數二者基本相同.

這裏面確有一些相同點，可是他們也存在着巨大的差別.

讓咱們先從相同點談起.

你傳遞函數參數與異常的途徑能夠是傳值、傳遞引用或傳遞指針，這是相同的.

可是當你傳遞參數和異常時，系統所要完成的操做過程則是徹底不一樣的.

產生這個差別的緣由是：你調用函數時，程序的控制權最終還會返回到函數的調用處，可是當你拋出一個異常時，控制權永遠不會回到拋出異常的地方。

有這樣一個函數，參數類型是Widget，並拋出一個Widget類型的異常：

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

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

這與拋出localWidget異常有很大不一樣.

不論經過傳值捕獲異常仍是經過引用捕獲（不能經過指針捕獲這個異常，由於類型不匹配）都將進行lcalWidget的拷貝操做，也就說傳遞到catch子句中的是localWidget的拷貝.

必須這麼作，由於當localWidget離開了生存空間後，其析構函數將被調用.

若是把localWidget自己（而不是它的拷貝）傳遞給catch子句，這個子句接收到的只是一個被析構了的Widget，一個Widget的「屍體」.

這是沒法使用的。所以C++規範要求被作爲異常拋出的對象必須被複制.

即便被拋出的對象不會被釋放，也會進行拷貝操做.

例如若是passAndThrowWidget函數聲明localWidget爲靜態變量（static），

void  passAndThrowWidget()
{
      static  Widget  localWidget;         // 如今是靜態變量（static） 一直存在至程序結束
      cin  >>  localWidget;                // 象之前那樣運行
      throw  localWidget;                 // 仍將對localWidget進行拷貝操做
}

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

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

對異常對象進行強制複製拷貝，這個限制有助於咱們理解參數傳遞與拋出異常的第二個差別：拋出異常運行速度比參數傳遞要慢.

當異常對象被拷貝時，拷貝操做是由對象的拷貝構造函數完成的.

該拷貝構造函數是對象的靜態類型（static type）所對應類的拷貝構造函數，而不是對象的動態類型（dynamic type）對應類的拷貝構造函數.

好比如下這通過少量修改的passAndThrowWidget：

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

這裏拋出的異常對象是Widget，即便rw引用的是一個SpecialWidget.

由於rw的靜態類型（static type）是Widget，而不是SpecialWidget.

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

這種行爲可能與你所期待的不同，可是這與在其餘狀況下C++中拷貝構造函數的行爲是一致的.

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

異常是其它對象的拷貝，這個事實影響到你如何在catch塊中再拋出一個異常.

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

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

這兩個catch塊的差異在於第一個catch塊中從新拋出的是當前捕獲的異常，而第二個catch塊中從新拋出的是當前捕獲異常的一個新的拷貝.

若是忽略生成額外拷貝的系統開銷，這兩種方法還有差別麼？
固然有。第一個塊中從新拋出的是當前異常（current exception）,不管它是什麼類型.

特別是若是這個異常開始就是作爲SpecialWidget類型拋出的，那麼第一個塊中傳遞出去的仍是SpecialWidget異常，即便w的靜態類型（static type）是Widget.

這是由於從新拋出異常時沒有進行拷貝操做.

第二個catch塊從新拋出的是新異常，類型老是Widget，由於w的靜態類型（static type）是Widget.

通常來講，你應該用throw來從新拋出當前的異常，由於這樣不會改變被傳遞出去的異常類型，並且更有效率，由於不用生成一個新拷貝.

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

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

不過我想你的編譯器很難這麼作，由於程序中不多發生異常，因此編譯器廠商不會在這方面花大量的精力）

讓咱們測試一下下面這三種用來捕獲Widget異常的catch子句，異常是作爲passAndThrowWidgetp拋出的：

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

咱們馬上注意到了傳遞參數與傳遞異常的另外一個差別.

一個被異常拋出的對象（剛纔解釋過，老是一個臨時對象）能夠經過普通的引用捕獲.

它不須要經過指向const對象的引用（reference-to-const）捕獲.

在函數調用中不容許轉遞一個臨時對象到一個非const引用類型的參數裏（參見條款19），可是在異常中卻被容許.

讓咱們先無論這個差別，回到異常對象拷貝的測試上來.

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

一樣咱們經過傳值的方式傳遞一個異常時，也是這麼作的。當咱們這樣聲明一個catch子句時:

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

會創建兩個被拋出對象的拷貝，一個是全部異常都必須創建的臨時對象，第二個是把臨時對象拷貝進w中.

一樣，當咱們經過引用捕獲異常時:

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

這仍舊會創建一個被拋出對象的拷貝：拷貝是一個臨時對象.

相反當咱們經過引用傳遞函數參數時，沒有進行對象拷貝.

當拋出一個異常時，系統構造的（之後會析構掉）被拋出對象的拷貝數比以相同對象作爲參數傳遞給函數時構造的拷貝數要多一個.

咱們尚未討論經過指針拋出異常的狀況，不過經過指針拋出異常與經過指針傳遞參數是相同的.

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

你不能認爲拋出的指針是一個指向局部對象的指針，由於當異常離開局部變量的生存空間時，該局部變量已經被釋放.

Catch子句將得到一個指向已經不存在的對象的指針。這種行爲在設計時應該予以免.

對象從函數的調用處傳遞到函數參數裏與從異常拋出點傳遞到catch子句裏所採用的方法不一樣，

這只是參數傳遞與異常傳遞的區別的一個方面，第二個差別是在函數調用者或拋出異常者與被調用者或異常捕獲者之間的類型匹配的過程不一樣.

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

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

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

int i;
double sqrtOfi = sqrt(i);

毫無疑問，C++容許進行從int到double的隱式類型轉換，因此在sqrt的調用中，i 被悄悄地轉變爲double類型，而且其返回值也是double.

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

見下面的代碼：

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

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

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

所以若是要想捕獲int異常，必須使用帶有int或int&參數的catch子句.

不過在catch子句中進行異常匹配時能夠進行兩種類型轉換.

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

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

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

捕獲runtime_errors異常的Catch子句能夠捕獲range_error類型和overflow_error類型的異常，

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

這種派生類與基類（inheritance_based）間的異常類型轉換能夠做用於數值、引用以及指針上：

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

第二種是容許從一個類型化指針（typed pointer）轉變成無類型指針（untyped pointer），

因此帶有const void* 指針的catch子句能捕獲任何類型的指針類型異常：

catch (const void*) ...                 file://捕獲任何指針類型異常
 
傳遞參數和傳遞異常間最後一點差異是catch子句匹配順序老是取決於它們在程序中出現的順序.

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

例如：

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

與上面這種行爲相反，當你調用一個虛擬函數時，被調用的函數位於與發出函數調用的對象的動態類型（dynamic type）最相近的類裏.

你能夠這樣說虛擬函數採用最優適合法，而異常處理採用的是最早適合法.

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

（由於這樣的代碼在C++裏一般是不合法的）

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

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

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

綜上所述，把一個對象傳遞給函數或一個對象調用虛擬函數與把一個對象作爲異常拋出，這之間有三個主要區別.

第1、異常對象在傳遞時總被進行拷貝；當經過傳值方式捕獲時，異常對象被拷貝了兩次.

對象作爲參數傳遞給函數時不須要被拷貝.

第2、對象作爲異常被拋出與作爲參數傳遞給函數相比，前者類型轉換比後者要少（前者只有兩種轉換形式）.

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

當一個對象調用一個虛擬函數時，被選擇的函數位於與對象類型匹配最佳的類裏，即便該類不是在源代碼的最前頭.

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

其實靈巧指針的做用很大，對咱們來講垃圾回收，ATL等都會使用到它.

在More effective 的條款後面特地增長這個節點，不只是想介紹它在異常處理方面的做用，還但願對編寫別的類型代碼的時候能夠有所幫助.

smart pointer（靈巧指針）其實並非一個指針,實際上是某種形式的類.

不過它的特長就是模仿C/C++中的指針，因此就叫pointer 了.

因此但願你們必定要記住兩點：smart pointer是一個類而非指針，但特長是模仿指針.

那怎麼作到像指針的呢？

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

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

其次須要模仿指針主要的兩個運算符->和*，那就須要進行運算符重載.

詳細的實現：

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

這只是一個大概的印象，不少東西是能夠更改的.

好比能夠去掉或加上一些const ，這都須要根據具體的應用環境而定.

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

而因爲smart pointer是一個類，在構造函數、析構函數中均可以經過恰當的編程達到一些不錯的效果.
舉例：
好比C++標準庫裏的std::auto_ptr 就是應用很廣的一個例子.

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

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

關於auto_ptr 的使用能夠找到不少的列子，這裏不在舉了.

它的主要優勢是不用 delete ，能夠自動回收已經被分配的空間，由此能夠避免資源泄露的問題.

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

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

而且即便在產生異常的狀況下， auto_ptr 也能正確地回收資源.

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

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

針對不一樣的smart pointer ，有不一樣的注意事項。好比auto_ptr ，就不能把它用在標準容器裏，由於它只在內存中保留一份實例.

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

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

SmartPtr p; 
if(p==0) 
if(!p) 
if(p) 
很顯然， p 不是一個真正的指針，這麼作可能出錯.

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

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

若是堅持非要用上面的形式， 那也是能夠的,咱們就加上operator void* ()試試： 

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

這種方法在basic_ios 中就使用過了。這裏也能夠更靈活地處理，好比類自己須要operator void*()這樣地操做，

那麼上面這種方法就不靈了。但咱們還有重載operator !()等等方法來實現.
總結smart pointer的實質： 
smart pointer 的實質就是一個外殼，一層包裝。正是多了這層包裝，咱們能夠作出許多普通指針沒法完成的事，好比前面資源自動回收，或者自動進行引用記數，好比ATL 中CComPtr 和 CComQIPtr 這兩個COM 接口指針類.

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

WIN結構化異常

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

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

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

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

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

必定要記得在背後的事情：在使用SEH的時候，編譯程序和操做系統直接參與了程序代碼的執行。

Win32異常事件的理解

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

Exception（異常處理） 分紅軟件和硬件exception2種.如：一個無效的參數或者被0除都會引發軟件exception，而訪問一個還沒有commit的頁會引發硬件exception.

發生異常的時候，執行流程終止，同時控制權轉交給操做系統，OS會用上下文（CONTEXT）結構把當前的進程狀態保存下來，而後就開始search 一個能處理exception的組件，search order以下：

1. 首先檢查是否有一個調試程序與發生exception的進程聯繫在一塊兒，推算這個調試程序是否有能力處理

2. 如上面不能完成，操做系統就在發生exception event的線程中search exception event handler

3. search與進程關聯在一塊兒的調試程序

4. 系統執行本身的exception event handler code and terminate process

結束處理程序

利用SEH，你能夠徹底不用考慮代碼裏是否是有錯誤，這樣就把主要的工做同錯誤處理分離開來.

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

微軟在Windows中引入SEH的主要動機是爲了便於操做系統自己的開發.

操做系統的開發人員使用SEH，使得系統更增強壯.咱們也可使用SEH，使咱們的本身的程序更增強壯.

使用SEH所形成的負擔主要由編譯程序來承擔，而不是由操做系統承擔.

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

編譯程序必須產生一些表（table）來支持處理SEH的數據結構.

編譯程序還必須提供回調（callback）函數，操做系統能夠調用這些函數，保證異常塊被處理.

編譯程序還要負責準備棧結構和其餘內部信息，供操做系統使用和參考.

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

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

幸好咱們能夠沒必要考慮編譯程序的實現細節，而只使用編譯程序的SEH功能.

（其實大多數編譯程序廠商都採用微軟建議的語法）

 

結束處理程序代碼初步

一個結束處理程序可以確保去調用和執行一個代碼塊（結束處理程序，termination handler），

而無論另一段代碼（保護體， guarded body）是如何退出的。結束處理程序的語法結構以下： __try
{
   file://保護塊
}
__finally
{
  file://結束處理程序
}
在上面的代碼段中，操做系統和編譯程序共同來確保結束處理程序中的__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;
}

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

這個return語句告訴編譯程序在這裏要退出這個函數並返回dwTemp變量的內容，如今這個變量的值是5.

可是，若是這個return語句被執行，該線程將不會釋放信標，其餘線程也就不能再得到對信標的控制.

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

經過使用結束處理程序，能夠避免return語句的過早執行.

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

要保證finally塊中的代碼在try塊中的return語句退出以前執行.

在程序中，將ReleaseSemaphore的調用放在結束處理程序塊中，保證信標總會被釋放.

 

這樣就不會形成一個線程一直佔有信標，不然將意味着全部其餘等待信標的線程永遠不會被分配CPU時間.

在finally塊中的代碼執行以後，函數實際上就返回.

任何出如今finally塊之下的代碼將再也不執行，由於函數已在try塊中返回,因此這個函數的返回值是5，而不是10.

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

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

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

編譯程序而後再生成代碼來執行finally塊中包含的指令，這稱爲局部展開.

更特殊的狀況是，因爲try塊中存在過早退出的代碼，從而產生局部展開，致使系統執行finally塊中的內容.

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

能夠看到，要完成這些事情，編譯程序必須生成附加的代碼，系統要執行額外的工做.

在不一樣的CPU上，結束處理所須要的步驟也不一樣.

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

在編寫代碼時，就應該避免引發結束處理程序的try塊中的過早退出，由於程序的性能會受到影響.

後面，將討論__leave關鍵字，它有助於避免編寫引發局部展開的代碼.

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

若是狀況是正常的，明確地檢查這些狀況，比起依賴操做系統和編譯程序的SEH功能來捕捉常見的事情要更有效.

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

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

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

========================

修改代碼：（返回值：5，沒有Leak，性能消耗：中）

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

代碼中，當編譯程序看到try塊中的goto語句，它首先生成一個局部展開來執行finally塊中的內容.

這一次，在finally塊中的代碼執行以後，在ReturnValue標號以後的代碼將執行，由於在try塊和finally塊中都沒有返回發生.

這裏的代碼使函數返回5,並且，因爲中斷了從try塊到finally塊的天然流程，可能要蒙受很大的性能損失（取決於運行程序的CPU）

 

 

寫上面的代碼是初步的，如今來看結束處理程序在咱們代碼裏面的真正的價值：
看代碼：（信號燈被正常釋放，reserve的一頁內存沒有被Free，安全性：安全）

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

 

finally塊的總結性說明

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

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

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

第三種狀況，全局展開（globalunwind），在發生的時候沒有明顯的標識，咱們在本章前面Func_SEHTerminate函數中已經見到.在Func_SEHTerminate的try塊中，有一個對TermHappenSomeError函數的調用。TermHappenSomeError函數會引發一個內存訪問違規（memory access violation），一個全局展開會使Func_SEHTerminate函數的finally塊執行.

因爲以上三種狀況中某一種的結果而致使finally塊中的代碼開始執行。爲了肯定是哪種狀況引發finally塊執行，能夠調用內部函數AbnormalTermination：這個內部函數只在finally塊中調用，返回一個Boolean值.指出與finally塊相結合的try塊是否過早退出。換句話說，若是控制流離開try塊並天然進入finally塊，AbnormalTermination將返回FALSE。若是控制流非正常退出try塊—一般因爲goto、return、break或continue語句引發的局部展開，或因爲內存訪問違規或其餘異常引發的全局展開—對AbnormalTermination的調用將返回TRUE。沒有辦法區別finally塊的執行是因爲全局展開仍是因爲局部展開.

但這一般不會成爲問題，由於能夠避免編寫執行局部展開的代碼.（注意內部函數是編譯程序識別的一種特殊函數。編譯程序爲內部函數產生內聯（inline）代碼而不是生成調用函數的代碼。例如，memcpy是一個內部函數（若是指定/Oi編譯程序開關）。當編譯程序看到一個對memcpy的調用，它直接將memcpy的代碼插入調用memcpy的函數中，而不是生成一個對memcpy函數的調用。其做用是代碼的長度增長了，但執行速度加快了。

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

•簡化錯誤處理，因全部的清理工做都在一個位置而且保證被執行。

•提升程序的可讀性。

•使代碼更容易維護。

•若是使用得當，具備最小的系統開銷。

異常處理程序

異常是咱們不但願有的事件。在編寫程序的時候，程序員不會想去存取一個無效的內存地址或用0來除一個數值。不過，這樣的錯誤仍是經常會發生的。CPU負責捕捉無效內存訪問和用0除一個數值這種錯誤，並相應引起一個異常做爲對這些錯誤的反應。CPU引起的異常，就是所謂的硬件異常（hardwareexception）。在本章的後面，咱們還會看到操做系統和應用程序也能夠引起相應的異常，稱爲軟件異常（softwareexception）。

當出現一個硬件或軟件異常時，操做系統嚮應用程序提供機會來考察是什麼類型的異常被引起，並可以讓應用程序本身來處理異常。下面就是異常處理程序的語法：

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

注意__ 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塊以後的第一條指令恢復。

  • c++異常參數傳遞
從語法上看，在函數裏聲明參數與在catch子句中聲明參數是同樣的，catch裏的參數能夠是值類型，引用類型，指針類型.例如：
try
{
      .....
}
catch( A  a)
{
}
catch(B & b)
{
}
catch( C *  c)
{
}
儘管表面是它們是同樣的，可是編譯器對兩者的處理卻又很大的不一樣.
調用函數時，程序的控制權最終還會返回到函數的調用處，可是拋出一個異常時，控制權永遠不會回到拋出異常的地方.
class  A;
void  func_throw()
{
      A  a;
      throw  a;   //拋出的是a的拷貝，拷貝到一個臨時對象裏
}
try
{
      func_throw();
}
catch( A  a)   //臨時對象的拷貝
{
}
當咱們拋出一個異常對象時，拋出的是這個異常對象的拷貝。當異常對象被拷貝時，拷貝操做是由對象的拷貝構造函數完成的.
該拷貝構造函數是對象的靜態類型(static type)所對應類的拷貝構造函數，而不是對象的動態類型(dynamic type)對應類的拷貝構造函數。此時對象會丟失RTTI信息.
異常是其它對象的拷貝，這個事實影響到你如何在catch塊中再拋出一個異常。好比下面這兩個catch塊，乍一看好像同樣:
catch( A &  w)   // 捕獲異常
{
     　 // 處理異常
     　 throw;  // 從新拋出異常，讓它繼續傳遞
}
catch( A &  w)   // 捕獲Widget異常
{
     　 // 處理異常
     　 throw  w;  // 傳遞被捕獲異常的拷貝
}
  第一個塊中從新拋出的是當前異常(current exception),不管它是什麼類型。（有多是A的派生類）  
  第二個catch塊從新拋出的是新異常，失去了原來的類型信息.
  通常來講，你應該用throw來從新拋出當前的異常，由於這樣不會改變被傳遞出去的異常類型，並且更有效率，由於不用生成一個新拷貝.
看看如下這三種聲明:
catch (A w) ... // 經過傳值
catch (A& w) ... // 經過傳遞引用
catch (const A& w) ... //const引用
一個被異常拋出的對象(老是一個臨時對象)能夠經過普通的引用捕獲;它不須要經過指向const對象的引用(reference-to-const)捕獲.
在函數調用中不容許轉遞一個臨時對象到一個非const引用類型的參數裏，可是在異常中卻被容許.
回到異常對象拷貝上來,咱們知道，當用傳值的方式傳遞函數的參數，咱們製造了被傳遞對象的一個拷貝，並把這個拷貝存儲到函數的參數裏.
一樣咱們經過傳值的方式傳遞一個異常時，也是這麼作的當咱們這樣聲明一個catch子句時:
catch (A w) ... // 經過傳值捕獲
會創建兩個被拋出對象的拷貝，一個是全部異常都必須創建的臨時對象，第二個是把臨時對象拷貝進w中。實際上，編譯器會優化掉一個拷貝。一樣，當咱們經過引用捕獲異常時，
catch (A& w) ... // 經過引用捕獲
catch (const A& w) ... //const引用捕獲
這仍舊會創建一個被拋出對象的拷貝:拷貝是一個臨時對象。相反當咱們經過引用傳遞函數參數時，沒有進行對象拷貝.
話雖如此，可是不是全部編譯器都如此,VS200就表現很詭異.
經過指針拋出異常與經過指針傳遞參數是相同的.
不論哪一種方法都是一個指針的拷貝被傳遞,你不能認爲拋出的指針是一個指向局部對象的指針，由於當異常離開局部變量的生存空間時，該局部變量已經被釋放.
Catch子句將得到一個指向已經不存在的對象的指針。這種行爲在設計時應該予以免.
另一個重要的差別是在函數調用者或拋出異常者與被調用者或異常捕獲者之間的類型匹配的過程不一樣.
在函數傳遞參數時，若是參數不匹配，那麼編譯器會嘗試一個類型轉換，若是存在的話。而對於異常處理的話，則徹底不是這樣。見一下的例子：
void  func_throw()
{
      CString  a;
      throw  a;   //拋出的是a的拷貝，拷貝到一個臨時對象裏
}
try
{
      func_throw();
}
catch( const  char * s)
{
     
}
拋出的是CString，若是用const char*來捕獲的話，是捕獲不到這個異常的.
儘管如此，在catch子句中進行異常匹配時能夠進行兩種類型轉換.第一種是基類與派生類的轉換，一個用來捕獲基類的catch子句也能夠處理派生類類型的異常.
反過來，用來捕獲派生類的沒法捕獲基類的異常.

第二種是容許從一個類型化指針(typed pointer)轉變成無類型指針(untyped pointer)，因此帶有const void* 指針的catch子句能捕獲任何類型的指針類型異常:
catch (const void*) ... //能夠捕獲全部指針異常
另外，你還能夠用catch(...)來捕獲全部異常，注意是三個點.
傳遞參數和傳遞異常間最後一點差異是catch子句匹配順序老是取決於它們在程序中出現的順序.
所以一個派生類異常可能被處理其基類異常的catch子句捕獲，這叫異常截獲，通常的編譯器會有警告.
class  A
{
public :
      A()
      {
            cout  <<  "class A creates"  <<  endl;
      }
      void  print()
      {
            cout  <<  "A"  <<  endl;
      }
      ~ A()
      {
            cout  <<  "class A destruct"  <<  endl;
      }
};
class B :  public  A
{
public :
     B()
      {
            cout  <<  "class B create"  <<  endl;
      }
      void  print()
      {
            cout  <<  "B"  <<  endl;
      }
      ~B()
      {
            cout  <<  "class B destruct"  <<  endl;
      }
};
void  func()
{
     B b;
      throw b;
}
try
{
      func();
}
catch(B & b)   //必須將B放前面，若是把A放前面，B放後面，那麼B類型的異常會先被截獲。
{
     b . print();
}
catch( A &  a)
{
      a . print() ;
}
 
 
相反的是，當你調用一個虛擬函數時，被調用的函數位於與發出函數調用的對象的動態類型(dynamic type)最相近的類裏.
 
你能夠這樣說虛擬函數匹配採用最優匹配法，而異常處理匹配採用的是最早匹配法.

附：
異常的描述

函數和函數可能拋出的異常集合做爲函數聲明的一部分是有價值的，例如

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

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

若是f函數違反了這個規定，拋出了x2,x3以外的異常,例如x4,那麼當函數f拋出x4異常時，

會轉換爲一個std::unexpected()調用，默認是調用std::terminate(),一般是調用abort().

若是函數不帶異常描述，那麼假定他可能拋出任何異常,例如:

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

不帶任何異常的函數能夠用空表表示:

int  g()  throw();   // 不會拋出任何異常
 
 
本文章部份內容參考hellodev的博客
 
轉載請註明出處:http://www.cnblogs.com/crazyacking/p/4951638.html ，侵權必究.
 
分類:  編程語言 - C++
標籤:  C++,  異常處理
好文要頂  關注我  收藏該文   
6
0
 
(請您對文章作出評價)
 
« 上一篇： 暴搜 - Codeforces Round #327 (Div. 2) E. Three States
» 下一篇： 未發佈020
posted @  2015-11-09 23:33  crazyacking 閱讀( 495) 評論( 4)  編輯  收藏
相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程