C++處理異常 try,catch,throw,finally

時間 2019-11-09

標籤 c++ 處理異常 try catch throw finally 欄目 C&C++ 简体版

原文原文鏈接

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

也許咱們已經使用過異常，可是你會是一種習慣嗎，不要總是想着當我打開一個文件的時候才用異常判斷一下，我知道對你來講你喜歡用return value或者是print error message來作，你想過這樣作會致使Memory Leak，系統退出，代碼重複/難讀，垃圾一堆…..嗎？如今的軟件已是n*365*24小時的運行了，軟件的健壯已是一個很要考慮的時候了。
自序：
對寫程序來講異常真的是很重要，一個穩健的代碼不是靠返回Error Message/return Value來解決的，但是每每咱們從C走過來，習慣了這樣的方式。java

內容導讀：
（請打開文檔結構圖來讀這篇文章。）
本文包括異常實現概念：C++的標準異常ios

C++標準異常：也許咱們瞭解過他，但你有考慮過，其實你根本不會使用，你不相信，那我問你：垃圾回收在C++中怎麼實現？其實不須要實現，C++已經有了，可是你不會用，那麼從<構造和析構中的異常拋出>開始看把。也許很高興看到錯誤以後的Heap/Stack中對象被釋放，但是若是沒有呢？有或者試想一下一個能解決的錯誤，須要咱們把整個程序Kill掉嗎？
在C++標準異常中我向你推薦這幾章：<使用異常規格編程> <構造和析構中的異常拋出> <使用析構函數防止資源泄漏> 以及一個深點的<拋出一個異常的行爲>
另，《使用析構函數防止資源泄漏》這個節點引用了More effective C++的條款9，用2個列子，講述了咱們通常都會犯下的錯誤，每每這種錯誤是咱們沒有意識到的但確實是會給咱們的軟件帶來致命的Leak/Crash，但這是有解決的方法的，那就是使用「靈巧指針」。c++

若是對照<More effective C++>的37條條款，關於異常的高級使用，有如下內容是沒有完成的：
l 使用構造函數防止資源Leak（More effective C++ #10）
l 禁止異常信息傳遞到析構Function外 (More effective C++ #11)
l 經過引用捕獲異常（More effective C++ #13）
l 謹慎使用異常規格（More effective C++ #14）
l 瞭解異常處理形成的系統開銷（More effective C++ #15）
l 限制對象數量（More effective C++ #26）
l 靈巧指針（More effective C++ #28）
[聲明：節點：<使用析構函數防止資源泄漏> 和節點：<拋出一個異常的行爲>中有大量的關於More effective C++的條款，因此本文擋只用於自我閱讀和內部交流，任何公開化和商業化，事先聲明與本人無關。]程序員

C++異常
C++引入異常的緣由
C++新增的異常機制改變了某些事情，這些改變是完全的，但這些改變也可能讓咱們不舒服。例如使用未經處理的pointer變的很危險，Memory/Resource Leak變的更有可能了（別說什麼Memory便宜了，那不是一個優秀的程序員說的話。），寫出一個具備你但願的行爲的構造函數和析構函數也變的困難（不可預測），固然最危險的也許是咱們寫出的東東狗屁了，或者是速度變慢了。編程

大多數的程序員知道How to use exception 來處理咱們的代碼，但是不少人並非很重視異常的處理（國外的不少Code卻是處理的很好，Java的Exception機制很不錯）。異常處理機制是解決某些問題的上佳辦法，但同時它也引入了許多隱藏的控制流程；有時候，要正確無誤的使用它並不容易。windows

在異常被throw後，沒有一個方法可以作到使軟件的行爲具備可預測性和可靠性（這句話不是我說的，是Jack Reeves寫的Coping with Exception和Herb Sutter寫的Exception-Safe Generic Containers中的。）一個沒有按照異常安全設計的程序想Run 正常，是作夢，別去想沒有異常出現的可能，數組

對C程序來講，使用Error Code就能夠了，爲何還要引入異常？由於異常不能被忽略。若是一個函數經過設置一個狀態變量或返回錯誤代碼來表示一個異常狀態，沒有辦法保證函數調用者將必定檢測變量或測試錯誤代碼。結果程序會從它遇到的異常狀態繼續運行，異常沒有被捕獲，程序當即會終止執行。安全

在C程序中，咱們能夠用int setjmp( jmp_buf env );和 void longjmp( jmp_buf env, int value );這2個函數來完成和異常處理相識的功能，可是MSDN中介紹了在C++中使用longjmp來調整stack時不可以對局部的對象調用析構函數，可是對C++程序來講，析構函數是重要的（我就通常都把對象的Delete放在析構函數中）。
因此咱們須要一個方法：①可以通知異常狀態，又不能忽略這個通知，②而且Searching the stack以便找到異常代碼時，③還要確保局部對象的析構函數被Call。而C++的異常處理恰好就是來解決這些問題的。數據結構

有的地方只有用異常才能解決問題，好比說，在當前上下文環境中，沒法捕捉或肯定的錯誤類型，咱們就得用一個異常拋出到更大的上下文環境當中去。還有，異常處理的使用呢，能夠使出錯處理程序與「一般」代碼分離開來，使代碼更簡潔更靈活。另外就是程序必不可少的健壯性了，異常處理每每在其中扮演着重要的角色。

C++使用throw關鍵字來產生異常，try關鍵字用來檢測程序塊，catch關鍵字用來填寫異常處理的代碼。異常能夠由一個肯定類或派生類的對象產生。C++能釋放堆棧，並可清除堆棧中全部的對象。

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

throw異常類編程
拋出異經常使用throw，如：
throw ExceptionClass(「my throw「); //括號中的字符串是構造函數的參數。

例句中，ExceptionClass是一個類，它的構造函數以一個字符串作爲參數。也就是說，在throw的時候，C++的編譯器先構造一個ExceptionClass的對象，讓它做爲throw的值拋出去。同時，程序返回，調用析構。看下面這個程序：

 1 #include <iostream.h>
 2 class ExceptionClass{
 3     char* name;
 4 public:
 5 　　　ExceptionClass(const char* name="default name") 
 6 　　{
 7         cout<<"Construct "<<name<<endl;
 8         this->name=name;
 9     }
10 　　~ExceptionClass()
11 　　{
12         cout<<"Destruct "<<name<<endl;
13 　　}
14 　　void mythrow()
15 　　{
16        throw ExceptionClass("my throw");
17 
18 　　}
19 };
20 
21 void main(){
22        ExceptionClass e("Test");
23        try{
24            e.mythrow();
25      　　} 
26      　catch(...)
27     　 {
28          cout<<」*********」<<endl;
29        }
30 }
31 /*
32 這是輸出信息：
33 Construct Test
34 Construct my throw
35 Destruct my throw
36 ****************
37 Destruct my throw   （這裏是異常處理空間中對異常類的拷貝的析構）
38 Destruct Test
39 */

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

 1 class ExceptionClass{
 2 public:
 3      ExceptionClass(const char* name="Exception Default Class"){
 4           cout<<"Exception Class Construct String"<<endl;
 5      }
 6      ~ExceptionClass(){
 7           cout<<"Exception Class Destruct String"<<endl;
 8      }
 9      void ReportError() {
10           cout<<"Exception Class:: This is Report Error Message"<<endl;
11      }
12 };
13 
14 class ArguClass{
15     char* name;
16 public:
17     ArguClass(char* name="default name"){
18          cout<<"Construct String::"<<name<<endl;
19          this->name=name;
20     }
21     ~ArguClass(){
22          cout<<"Destruct String::"<<name<<endl;
23     }
24     void mythrow(){
25          throw ExceptionClass("my throw");
26     }       
27 };
28 
29 void main()
30 {
31     ArguClass e("haha");
32     try {
33         e.mythrow();
34     } 
35     catch(int)
36     {
37         cout<<"If This is Message display screen, This is a Error!!"<<endl;
38     }
39     catch(ExceptionClass pTest) 
40     {
41          pTest.ReportError();
42     }
43     catch(...){
44          cout<<"***************"<<endl;  
45     }
46 }
47 /*
48 輸出Message：
49 Construct String::haha
50 Exception Class Construct String
51 Exception Class Destruct String
52 Exception Class:: This is Report Error Message
53 Exception Class Destruct String
54 Destruct String::haha
55 */

使用異常規格編程
若是咱們調用別人的函數，裏面有異常拋出，用去查看它的源代碼去看看都有什麼異常拋出嗎？這樣就會很煩瑣。比較好的解決辦法，是編寫帶有異常拋出的函數時，採用異常規格說明，使咱們看到函數聲明就知道有哪些異常出現。

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

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

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

注意下面一種形式：

void ExceptionFunction(argument…) throw()

代表沒有任何異常拋出。

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

異常捕獲以後，能夠再次拋出，就用一個不帶任何參數的throw語句就能夠了。
構造和析構中的異常拋出
這是異常處理中最要注意的地方了

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

 1 #include <iostream.h>
 2 #include <stdlib.h>
 3 
 4 class ExceptionClass1
 5 {
 6        char* s;
 7 public:
 8        ExceptionClass1(){
 9               cout<<"ExceptionClass1()"<<endl;
10               s=new char[4];
11               cout<<"throw a exception"<<endl;
12               throw 18;
13        }
14        ~ExceptionClass1(){
15               cout<<"~ExceptionClass1()"<<endl;
16               delete[] s;
17        }
18 };
19 
20 void main(){
21        try{
22              ExceptionClass1 e;
23        }catch(...)
24        {}
25 }
26 /*
27 結果爲：
28 ExceptionClass1()
29 throw a exception
30 */

在這兩句輸出之間，咱們已經給S分配了內存，但內存沒有被釋放（由於它是在析構函數中釋放的）。應該說這符合實際現象，由於對象沒有完整構造。

爲了不這種狀況，我想你也許會說：應避免對象經過自己的構造函數涉及到異常拋出。即：既不在構造函數中出現異常拋出，也不該在構造函數調用的一切東西中出現異常拋出。

可是在C++中能夠在構造函數中拋出異常，經典的解決方案是使用STL的標準類auto_ptr。
其實咱們也能夠這樣作來實現：在類中增長一個 Init(); 以及 UnInit();成員函數用於進行容易產生錯誤的資源分配工做，而真正的構造函數中先將全部成員置爲NULL，而後調用 Init(); 並判斷其返回值/或者捕捉 Init()拋出的異常，若是Init();失敗了，則在構造函數中調用 UnInit(); 並設置一個標誌位代表構造失敗。UnInit()中按照成員是否爲NULL進行資源的釋放工做。

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

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

① 一個基類：
exception   是全部C++異常的基類。
class exception {
public:
    exception() throw();
    exception(const exception& rhs) throw();
    exception& operator=(const exception& rhs) throw();
    virtual ~exception() throw();
    virtual const char *what() const throw();
};

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

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

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

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

③ 由logic_erro派生的異常類

domain_error 報告違反了前置條件

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

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

out_of_range 報告參數越界

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

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

④ 由runtime_error派生的異常

range_error 報告違反了後置條件

overflow_error 報告一個算術溢出

bad_alloc 報告一個存儲分配錯誤

使用析構函數防止資源泄漏
這部分是一個經典和很日常就會遇到的實際狀況，下面的內容大部分都是從More Effective C++條款中獲得的。

假設，你正在爲一個小動物收容所編寫軟件，小動物收容所是一個幫助小狗小貓尋找主人的組織。天天收容所創建一個文件，包含當天它所管理的收容動物的資料信息，你的工做是寫一個程序讀出這些文件而後對每一個收容動物進行適當的處理（appropriate processing）。

完成這個程序一個合理的方法是定義一個抽象類，ALA（"Adorable Little Animal")，而後爲小狗和小貓創建派生類。一個虛擬函數processAdoption分別對各個種類的動物進行處理：

class ALA {

public:

　virtual void processAdoption() = 0;

　...

};

class Puppy: public ALA {

public:

　virtual void processAdoption();

　...

};

class Kitten: public ALA {

public:

　virtual void processAdoption();

　...

};

你須要一個函數從文件中讀信息，而後根據文件中的信息產生一個puppy（小狗）對象或者kitten(小貓)對象。這個工做很是適合於虛擬構造器（virtual constructor），在條款25詳細描述了這種函數。爲了完成咱們的目標，咱們這樣聲明函數：

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

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

ALA * readALA(istream& s);

你的程序的關鍵部分就是這個函數，以下所示：
void processAdoptions(istream& dataSource)

{

　while (dataSource) {　　　　　　　　　// 還有數據時,繼續循環

　　ALA *pa = readALA(dataSource);　　　file://得到下一個動物

　　pa->processAdoption();　　　　　　 file://處理收容動物

　　delete pa;　　　　　　　　　　　　 file://刪除readALA返回的對象

　}　　　　　　　　　　　　　　　　　

這個函數循環遍歷dataSource內的信息，處理它所遇到的每一個項目。惟一要記住的一點是在每次循環結尾處刪除ps。這是必須的，由於每次調用readALA都創建一個堆對象。若是不刪除對象，循環將產生資源泄漏。

如今考慮一下，若是pa->processAdoption拋出了一個異常，將會發生什麼？
processAdoptions沒有捕獲異常，因此異常將傳遞給processAdoptions的調用者。轉遞中，processAdoptions函數中的調用pa->processAdoption語句後的全部語句都被跳過，這就是說pa沒有被刪除。結果，任什麼時候候pa->processAdoption拋出一個異常都會致使processAdoptions內存泄漏。

堵塞泄漏很容易，

void processAdoptions(istream& dataSource)

{

　while (dataSource) {

　　ALA *pa = readALA(dataSource);

　try {

　　　pa->processAdoption();

　}

　catch (...) {　　　　　　　// 捕獲全部異常

　　delete pa;　　　　　　　 // 避免內存泄漏

　　　　　　　　　　　　　　 // 當異常拋出時

　　throw;　　　　　　　　　 // 傳送異常給調用者

　}

　delete pa;　　　　　　　　 // 避免資源泄漏

}　　　　　　　　　　　　　 // 當沒有異常拋出時

}

可是你必須用try和catch對你的代碼進行小改動。更重要的是你必須寫雙份清除代碼，一個爲正常的運行準備，一個爲異常發生時準備。在這種狀況下，必須寫兩個delete代碼。象其它重複代碼同樣，這種代碼寫起來使人心煩又難於維護，並且它看上去好像存在着問題。不論咱們是讓processAdoptions正常返回仍是拋出異常，咱們都須要刪除pa，因此爲何咱們必需要在多個地方編寫刪除代碼呢？

咱們能夠把總被執行的清除代碼放入processAdoptions函數內的局部對象的析構函數裏，這樣能夠避免重複書寫清除代碼。由於當函數返回時局部對象老是被釋放，不管函數是如何退出的。（僅有一種例外就是當你調用longjmp時。Longjmp的這個缺點是C++率先支持異常處理的主要緣由）

具體方法是用一個對象代替指針pa，這個對象的行爲與指針類似。當pointer-like（類指針）對象被釋放時，咱們能讓它的析構函數調用delete。替代指針的對象被稱爲smart pointers（靈巧指針），下面有解釋，你能使得pointer-like對象很是靈巧。在這裏，咱們用不着這麼聰明的指針，咱們只須要一個pointer-lik對象，當它離開生存空間時知道刪除它指向的對象。

寫出這樣一個類並不困難，可是咱們不須要本身去寫。標準C++庫函數包含一個類模板，叫作auto_ptr，這正是咱們想要的。每個auto_ptr類的構造函數裏，讓一個指針指向一個堆對象（heap object），而且在它的析構函數裏刪除這個對象。下面所示的是auto_ptr類的一些重要的部分：

template<class T>

class auto_ptr {

public:

　auto_ptr(T *p = 0): ptr(p) {}　　　　// 保存ptr，指向對象

　~auto_ptr() { delete ptr; }　　　　　// 刪除ptr指向的對象

private:

　T *ptr;　　　　　　　　　　　　　　　// raw ptr to object

};

auto_ptr類的完整代碼是很是有趣的，上述簡化的代碼實現不能在實際中應用。（咱們至少必須加上拷貝構造函數，賦值operator以及下面將要講到的pointer-emulating函數），可是它背後所蘊含的原理應該是清楚的：用auto_ptr對象代替raw指針，你將再也不爲堆對象不能被刪除而擔憂，即便在拋出異常時，對象也能被及時刪除。(由於auto_ptr的析構函數使用的是單對象形式的delete，因此auto_ptr不能用於指向對象數組的指針。若是想讓auto_ptr相似於一個數組模板，你必須本身寫一個。在這種狀況下，用vector代替array可能更好)

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

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

void processAdoptions(istream& dataSource)

{

　while (dataSource) {

　　auto_ptr<ALA> pa(readALA(dataSource));

　　pa->processAdoption();

　}

這個版本的processAdoptions在兩個方面區別於原來的processAdoptions函數。
第一， pa被聲明爲一個auto_ptr<ALA>對象，而不是一個raw ALA*指針。
第二，在循環的結尾沒有delete語句。
其他部分都同樣，由於除了析構的方式，auto_ptr對象的行爲就象一個普通的指針。是否是很容易。

隱藏在auto_ptr後的思想是：用一個對象存儲須要被自動釋放的資源，而後依靠對象的析構函數來釋放資源，這種思想不僅是能夠運用在指針上，還能用在其它資源的分配和釋放上。想一下這樣一個在GUI程序中的函數，它須要創建一個window來顯式一些信息：

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

void displayInfo(const Information& info)
{

　WINDOW_HANDLE w(createWindow());

　在w對應的window中顯式信息

　destroyWindow(w);

}

不少window系統有C－like接口，使用象like createWindow 和 destroyWindow函數來獲取和釋放window資源。若是在w對應的window中顯示信息時，一個異常被拋出，w所對應的window將被丟失，就象其它動態分配的資源同樣。

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

file://一個類，獲取和釋放一個window 句柄

class WindowHandle {

public:

　 WindowHandle(WINDOW_HANDLE handle): w(handle) {}

　~WindowHandle() { destroyWindow(w); }

　 operator WINDOW_HANDLE() { return w; }　　　　// see below

private:

　WINDOW_HANDLE w;

　// 下面的函數被聲明爲私有，防止創建多個WINDOW_HANDLE拷貝

　file://有關一個更靈活的方法的討論請參見下面的靈巧指針

　WindowHandle(const WindowHandle&);

　WindowHandle& operator=(const WindowHandle&);

};

這看上去有些象auto_ptr，只是賦值操做與拷貝構造被顯式地禁止（參見More effective C++條款27），有一個隱含的轉換操做能把WindowHandle轉換爲WINDOW_HANDLE。這個能力對於使用WindowHandle對象很是重要，由於這意味着你能在任何地方象使用raw WINDOW_HANDLE同樣來使用WindowHandle。（參見More effective C++條款5 ，瞭解爲何你應該謹慎使用隱式類型轉換操做）

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

// 若是一個異常被拋出，這個函數能避免資源泄漏

void displayInfo(const Information& info)

{

　WindowHandle w(createWindow());

　在w對應的window中顯式信息;

}

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

資源應該被封裝在一個對象裏，遵循這個規則，你一般就能避免在存在異常環境裏發生資源泄漏。可是若是你正在分配資源時一個異常被拋出，會發生什麼狀況呢？例如當你正處於resource-acquiring類的構造函數中。還有若是這樣的資源正在被釋放時，一個異常被拋出，又會發生什麼狀況呢？構造函數和析構函數須要特殊的技術。你能在More effective C++條款10和More effective C++條款11中獲取有關的知識。

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

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

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

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

你所以可能會認爲用throw拋出一個異常到catch子句中與經過函數調用傳遞一個參數二者基本相同。這裏面確有一些相同點，可是他們也存在着巨大的差別。

讓咱們先從相同點談起。你傳遞函數參數與異常的途徑能夠是傳值、傳遞引用或傳遞指針，這是相同的。可是當你傳遞參數和異常時，系統所要完成的操做過程則是徹底不一樣的。產生這個差別的緣由是：你調用函數時，程序的控制權最終還會返回到函數的調用處，可是當你拋出一個異常時，控制權永遠不會回到拋出異常的地方。

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

// 一個函數，從流中讀值到Widget中
istream operator>>(istream& s, Widget& w);
void passAndThrowWidget()
{
Widget localWidget;
cin >> localWidget; file://傳遞localWidget到 operator>>
throw localWidget; // 拋出localWidget異常
}
當傳遞localWidget到函數operator>>裏，不用進行拷貝操做，而是把operator>>內的引用類型變量w指向localWidget，任何對w的操做實際上都施加到localWidget上。這與拋出localWidget異常有很大不一樣。不論經過傳值捕獲異常仍是經過引用捕獲（不能經過指針捕獲這個異常，由於類型不匹配）都將進行lcalWidget的拷貝操做，也就說傳遞到catch子句中的是localWidget的拷貝。必須這麼作，由於當localWidget離開了生存空間後，其析構函數將被調用。若是把localWidget自己（而不是它的拷貝）傳遞給catch子句，這個子句接收到的只是一個被析構了的Widget，一個Widget的「屍體」。這是沒法使用的。所以C++規範要求被作爲異常拋出的對象必須被複制。

即便被拋出的對象不會被釋放，也會進行拷貝操做。例如若是passAndThrowWidget函數聲明localWidget爲靜態變量（static），

void passAndThrowWidget()
{
static Widget localWidget;        // 如今是靜態變量（static）;
                                    file://一直存在至程序結束

cin >> localWidget;               // 象之前那樣運行
throw localWidget;                // 仍將對localWidget
}                                   file://進行拷貝操做
當拋出異常時仍將複製出localWidget的一個拷貝。這表示即便經過引用來捕獲異常，也不能在catch塊中修改localWidget；僅僅能修改localWidget的拷貝。對異常對象進行強制複製拷貝，這個限制有助於咱們理解參數傳遞與拋出異常的第二個差別：拋出異常運行速度比參數傳遞要慢。

當異常對象被拷貝時，拷貝操做是由對象的拷貝構造函數完成的。該拷貝構造函數是對象的靜態類型（static type）所對應類的拷貝構造函數，而不是對象的動態類型（dynamic type）對應類的拷貝構造函數。好比如下這通過少量修改的passAndThrowWidget：
class Widget { ... };
class SpecialWidget: public Widget { ... };
void passAndThrowWidget()
{
SpecialWidget localSpecialWidget;
...
Widget& rw = localSpecialWidget;      // rw 引用SpecialWidget
throw rw;                             file://它拋出一個類型爲Widget
                                        // 的異常
}
這裏拋出的異常對象是Widget，即便rw引用的是一個SpecialWidget。由於rw的靜態類型（static type）是Widget，而不是SpecialWidget。你的編譯器根本沒有主要到rw引用的是一個SpecialWidget。編譯器所注意的是rw的靜態類型（static type）。這種行爲可能與你所期待的不同，可是這與在其餘狀況下C++中拷貝構造函數的行爲是一致的。（不過有一種技術可讓你根據對象的動態類型dynamic type進行拷貝，參見條款25）
異常是其它對象的拷貝，這個事實影響到你如何在catch塊中再拋出一個異常。好比下面這兩個catch塊，乍一看好像同樣：

catch (Widget& w)                 // 捕獲Widget異常
{
...                             // 處理異常
throw;                          // 從新拋出異常，讓它
}                                 // 繼續傳遞
catch (Widget& w)                 // 捕獲Widget異常
{
...                             // 處理異常
throw w;                        // 傳遞被捕獲異常的
}                                 // 拷貝
這兩個catch塊的差異在於第一個catch塊中從新拋出的是當前捕獲的異常，而第二個catch塊中從新拋出的是當前捕獲異常的一個新的拷貝。若是忽略生成額外拷貝的系統開銷，這兩種方法還有差別麼？
固然有。第一個塊中從新拋出的是當前異常（current exception）,不管它是什麼類型。特別是若是這個異常開始就是作爲SpecialWidget類型拋出的，那麼第一個塊中傳遞出去的仍是SpecialWidget異常，即便w的靜態類型（static type）是Widget。這是由於從新拋出異常時沒有進行拷貝操做。第二個catch塊從新拋出的是新異常，類型老是Widget，由於w的靜態類型（static type）是Widget。通常來講，你應該用
throw
來從新拋出當前的異常，由於這樣不會改變被傳遞出去的異常類型，並且更有效率，由於不用生成一個新拷貝。
（順便說一句，異常生成的拷貝是一個臨時對象。正如條款19解釋的，臨時對象能讓編譯器優化它的生存期（optimize it out of existence），不過我想你的編譯器很難這麼作，由於程序中不多發生異常，因此編譯器廠商不會在這方面花大量的精力。）
讓咱們測試一下下面這三種用來捕獲Widget異常的catch子句，異常是作爲passAndThrowWidgetp拋出的：
catch (Widget w) ...                // 經過傳值捕獲異常
catch (Widget& w) ...               // 經過傳遞引用捕獲
                                    // 異常
catch (const Widget& w) ...         file://通過傳遞指向const的引用
                                    file://捕獲異常
咱們馬上注意到了傳遞參數與傳遞異常的另外一個差別。一個被異常拋出的對象（剛纔解釋過，老是一個臨時對象）能夠經過普通的引用捕獲；它不須要經過指向const對象的引用（reference-to-const）捕獲。在函數調用中不容許轉遞一個臨時對象到一個非const引用類型的參數裏（參見條款19），可是在異常中卻被容許。
讓咱們先無論這個差別，回到異常對象拷貝的測試上來。咱們知道當用傳值的方式傳遞函數的參數，咱們製造了被傳遞對象的一個拷貝（參見Effective C++ 條款22），並把這個拷貝存儲到函數的參數裏。一樣咱們經過傳值的方式傳遞一個異常時，也是這麼作的。當咱們這樣聲明一個catch子句時：
catch (Widget w) ...                // 經過傳值捕獲
會創建兩個被拋出對象的拷貝，一個是全部異常都必須創建的臨時對象，第二個是把臨時對象拷貝進w中。一樣，當咱們經過引用捕獲異常時，
catch (Widget& w) ...               // 經過引用捕獲

catch (const Widget& w) ...         file://也經過引用捕獲
這仍舊會創建一個被拋出對象的拷貝：拷貝是一個臨時對象。相反當咱們經過引用傳遞函數參數時，沒有進行對象拷貝。當拋出一個異常時，系統構造的（之後會析構掉）被拋出對象的拷貝數比以相同對象作爲參數傳遞給函數時構造的拷貝數要多一個。
咱們尚未討論經過指針拋出異常的狀況，不過經過指針拋出異常與經過指針傳遞參數是相同的。不論哪一種方法都是一個指針的拷貝被傳遞。你不能認爲拋出的指針是一個指向局部對象的指針，由於當異常離開局部變量的生存空間時，該局部變量已經被釋放。Catch子句將得到一個指向已經不存在的對象的指針。這種行爲在設計時應該予以免。
對象從函數的調用處傳遞到函數參數裏與從異常拋出點傳遞到catch子句裏所採用的方法不一樣，這只是參數傳遞與異常傳遞的區別的一個方面，第二個差別是在函數調用者或拋出異常者與被調用者或異常捕獲者之間的類型匹配的過程不一樣。好比在標準數學庫（the standard math library）中sqrt函數：
double sqrt(double);                 // from <cmath> or <math.h>
咱們能這樣計算一個整數的平方根，以下所示：
int i;

double sqrtOfi = sqrt(i);
毫無疑問，C++容許進行從int到double的隱式類型轉換，因此在sqrt的調用中，i 被悄悄地轉變爲double類型，而且其返回值也是double。（有關隱式類型轉換的詳細討論參見條款5）通常來講，catch子句匹配異常類型時不會進行這樣的轉換。見下面的代碼：
void f(int value)
{
try {
    if (someFunction()) {      // 若是 someFunction()返回
      throw value;             file://真，拋出一個整形值
    ...
    }
}
catch (double d) {           // 只處理double類型的異常
    ...
}

...

}
在try塊中拋出的int異常不會被處理double異常的catch子句捕獲。該子句只能捕獲真真正正爲double類型的異常；不進行類型轉換。所以若是要想捕獲int異常，必須使用帶有int或int&參數的catch子句。
不過在catch子句中進行異常匹配時能夠進行兩種類型轉換。第一種是繼承類與基類間的轉換。一個用來捕獲基類的catch子句也能夠處理派生類類型的異常。例如在標準C++庫（STL）定義的異常類層次中的診斷部分（diagnostics portion ）(參見Effective C++ 條款49)。

捕獲runtime_errors異常的Catch子句能夠捕獲range_error類型和overflow_error類型的異常，能夠接收根類exception異常的catch子句能捕獲其任意派生類異常。
這種派生類與基類（inheritance_based）間的異常類型轉換能夠做用於數值、引用以及指針上：
catch (runtime_error) ...               // can catch errors of type
catch (runtime_error&) ...              // runtime_error,
catch (const runtime_error&) ...        // range_error, or
                                        // overflow_error
catch (runtime_error*) ...              // can catch errors of type
catch (const runtime_error*) ...        // runtime_error*,
                                        // range_error*, or
                                        // overflow_error*

第二種是容許從一個類型化指針（typed pointer）轉變成無類型指針（untyped pointer），因此帶有const void* 指針的catch子句能捕獲任何類型的指針類型異常：
catch (const void*) ...                 file://捕獲任何指針類型異常

傳遞參數和傳遞異常間最後一點差異是catch子句匹配順序老是取決於它們在程序中出現的順序。所以一個派生類異常可能被處理其基類異常的catch子句捕獲，即便同時存在有能處理該派生類異常的catch子句，與相同的try塊相對應。例如：
try {
...
}
catch (logic_error& ex) {              // 這個catch塊將捕獲
...                                  // 全部的logic_error
}                                      // 異常, 包括它的派生類

catch (invalid_argument& ex) {         // 這個塊永遠不會被執行
...                                  file://因爲全部的
}                                      // invalid_argument
                                       // 異常都被上面的
                                       // catch子句捕獲。
與上面這種行爲相反，當你調用一個虛擬函數時，被調用的函數位於與發出函數調用的對象的動態類型（dynamic type）最相近的類裏。你能夠這樣說虛擬函數採用最優適合法，而異常處理採用的是最早適合法。若是一個處理派生類異常的catch子句位於處理基類異常的catch子句前面，編譯器會發出警告。（由於這樣的代碼在C++裏一般是不合法的。）不過你最好作好預先防範：不要把處理基類異常的catch子句放在處理派生類異常的catch子句的前面。象上面那個例子，應該這樣去寫：
try {
...
}
catch (invalid_argument& ex) {          // 處理 invalid_argument
< src="/js/google-top_336X280.js" type="text/javascript"> < src="http://a.alimama.cn/inf.js" type="text/javascript">
file://異常
}
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 + +的異常處理，而且在內部實現上利用了已經引入到編譯程序和Wi n d o w s操做系統的結構化異常處理的功能。
S E H實際包含兩個主要功能：結束處理（ termination handling）和異常處理（ e x c e p t i o nh a n d l i n g）。
在MS VC的FAQ中有關於SHE的部分介紹，這裏摘超其中的一句：
「在VC5中，增長了新的/EH編譯選項用於控制C++異常處理。C++同步異常處理(/EH)使得編譯器能生成更少的代碼，/EH也是VC的缺省模型。」
必定要記得在背後的事情：在使用SHE的時候，編譯程序和操做系統直接參與了程序代碼的執行。
Win32異常事件的理解
我寫的另外一篇文章：內存處理和DLL技術也涉及到了SHE中的異常處理。
Exception（異常處理）分紅軟件和硬件exception 2種。如：一個無效的參數或者被0除都會引發軟件exception，而訪問一個還沒有commit的頁會引發硬件exception.
發生異常的時候，執行流程終止，同時控制權轉交給操做系統，OS會用上下文（CONTEXT）結構把當前的進程狀態保存下來，而後就開始search 一個能處理exception的組件，search order以下：
一、首先檢查是否有一個調試程序與發生exception的進程聯繫在一塊兒，推算這個調試程序是否有能力處理
二、如上面不能完成，操做系統就在發生exception event的線程中search exception event handler
三、 search與進程關聯在一塊兒的調試程序
四、系統執行本身的exception event handler code and terminate process
結束處理程序
利用S E H，你能夠徹底不用考慮代碼裏是否是有錯誤，這樣就把主要的工做同錯誤處理分離開來。這樣的分離，能夠使你集中精力處理眼前的工做，而將可能發生的錯誤放在後面處理。
微軟在Wi n d o w s中引入S E H的主要動機是爲了便於操做系統自己的開發。操做系統的開發人員使用S E H，使得系統更增強壯。咱們也能夠使用S E H，使咱們的本身的程序更增強壯。
使用S E H所形成的負擔主要由編譯程序來承擔，而不是由操做系統承擔。
當異常塊（exception block）出現時，編譯程序要生成特殊的代碼。編譯程序必須產生一些表（ t a b l e）來支持處理S E H的數據結構。
編譯程序還必須提供回調（ c a l l b a c k）函數，操做系統能夠調用這些函數，保證異常塊被處理。
編譯程序還要負責準備棧結構和其餘內部信息，供操做系統使用和參考。
在編譯程序中增長S E H支持不是一件容易的事。不一樣的編譯程序廠商會以不一樣的方式實現S E H，這一點並不讓人感到奇怪。幸好咱們能夠沒必要考慮編譯程序的實現細節，而只使用編譯程序的S E H功能。（其實大多數編譯程序廠商都採用微軟建議的語法）
結束處理程序代碼初步
一個結束處理程序可以確保去調用和執行一個代碼塊（結束處理程序，termination handler），
而無論另一段代碼（保護體， guarded body）是如何退出的。結束處理程序的語法結構以下：
__try
{
   file://保護塊
}
__finally
{
  file://結束處理程序
}
在上面的代碼段中，操做系統和編譯程序共同來確保結束處理程序中的__f i n a l l y代碼塊可以被執行，無論保護體（t r y塊）是如何退出的。不論你在保護體中使用r e t u r n，仍是g o t o，或者是longjump，結束處理程序（f i n a l l y塊）都將被調用。

=====================
************************
咱們來看一個實列：（返回值：10, 沒有Leak，性能消耗：小）
DWORD Func_SEHTerminateHandle()
{
DWORD dwReturnData = 0;
HANDLE hSem = NULL;
const char* lpSemName = "TermSem";
hSem = CreateSemaphore(NULL, 1, 1, lpSemName);
__try
{
  WaitForSingleObject(hSem,INFINITE);
  dwReturnData = 5;
}
__finally
{
  ReleaseSemaphore(hSem,1,NULL);
  CloseHandle(hSem);
}
dwReturnData += 5;
return dwReturnData;
}
這段代碼應該只是作爲一個基礎函數，咱們將在後面修改它，來看看結束處理程序的做用：
====================
在代碼加一句：（返回值：5, 沒有Leak，性能消耗：中下）
DWORD Func_SEHTerminateHandle()
{
DWORD dwReturnData = 0;
HANDLE hSem = NULL;
const char* lpSemName = "TermSem";
hSem = CreateSemaphore(NULL, 1, 1, lpSemName);
__try
{
  WaitForSingleObject(hSem,INFINITE);
  dwReturnData = 5;
  return dwReturnData;
}
__finally
{
  ReleaseSemaphore(hSem,1,NULL);
  CloseHandle(hSem);
}
dwReturnData += 5;
return dwReturnData;
}
在t r y塊的末尾增長了一個r e t u r n語句。這個r e t u r n語句告訴編譯程序在這裏要退出這個函數並返回d w Te m p變量的內容，如今這個變量的值是5。可是，若是這個r e t u r n
語句被執行，該線程將不會釋放信標，其餘線程也就不能再得到對信標的控制。能夠想象，這樣的執行次序會產生很大的問題，那些等待信標的線程可能永遠不會恢復執行。
經過使用結束處理程序，能夠避免r e t u r n語句的過早執行。當r e t u r n語句試圖退出t r y塊時，編譯程序要確保f i n a l l y塊中的代碼首先被執行。要保證f i n a l l y塊中的代碼在t r y塊中的r e t u r n語句退出以前執行。在程序中，將R e l e a s e S e m a p h o r e的調用放在結束處理程序塊中，保證信標總會被釋放。這樣就不會形成一個線程一直佔有信標，不然將意味着全部其餘等待信標的線程永遠不會被分配C P U時間。
在f i n a l l y塊中的代碼執行以後，函數實際上就返回。任何出如今f i n a l l y塊之下的代碼將再也不執行，由於函數已在t r y塊中返回。因此這個函數的返回值是5，而不是10。
讀者可能要問編譯程序是如何保證在t r y塊能夠退出以前執行f i n a l l y塊的。當編譯程序檢查源代碼時，它看到在t r y塊中有r e t u r n語句。這樣，編譯程序就生成代碼將返回值（本例中是5）保存在一個編譯程序創建的臨時變量中。編譯程序而後再生成代碼來執行f i n a l l y塊中包含的指令，這稱爲局部展開。更特殊的狀況是，因爲t r y塊中存在過早退出的代碼，從而產生局部展開，致使系統執行f i n a l l y塊中的內容。在f i n a l l y塊中的指令執行以後，編譯程序臨時變量的值被取出並從函數中返回。
能夠看到，要完成這些事情，編譯程序必須生成附加的代碼，系統要執行額外的工做。在
不一樣的C P U上，結束處理所須要的步驟也不一樣。例如，在A l p h a處理器上，必須執行幾百個甚至幾千個C P U指令來捕捉t r y塊中的過早返回並調用f i n a l l y塊。在編寫代碼時，就應該避免引發結束處理程序的t r y塊中的過早退出，由於程序的性能會受到影響。
後面，將討論_ _ l e a v e關鍵字，它有助於避免編寫引發局部展開的代碼。
設計異常處理的目的是用來捕捉異常的—不常發生的語法規則的異常狀況（在咱們的例子中，就是過早返回）。若是狀況是正常的，明確地檢查這些狀況，比起依賴操做系統和編譯程序的S E H功能來捕捉常見的事情要更有效。
注意當控制流天然地離開t r y塊並進入f i n a l l y塊（就像在F u n c e n s t e i n 1中）時，進入f i n a l l y塊的系統開銷是最小的。在x86 CPU上使用微軟的編譯程序，當執行離開try 塊進入f i n a l l y塊時，只有一個機器指令被執行，讀者能夠在本身的程序中注意到這種系統開銷。當編譯程序要生成額外的代碼，系統要執行額外的工做時系統開銷就很值得注意了
========================
修改代碼：（返回值：5，沒有Leak，性能消耗：中）
DWORD Func_SEHTerminateHandle()
{
DWORD dwReturnData = 0;
HANDLE hSem = NULL;
const char* lpSemName = "TermSem";
hSem = CreateSemaphore(NULL, 1, 1, lpSemName);
__try
{
  WaitForSingleObject(hSem,INFINITE);
  dwReturnData = 5;
  if(dwReturnData == 5)
   goto ReturnValue;
  return dwReturnData;
}
__finally
{
  ReleaseSemaphore(hSem,1,NULL);
  CloseHandle(hSem);
}
dwReturnData += 5;
ReturnValue:
return dwReturnData;
}
代碼中，當編譯程序看到t r y塊中的g o t o語句，它首先生成一個局部展開來執行f i n a l l y塊中的內容。這一次，在f i n a l l y塊中的代碼執行以後，在R e t u r n Va l u e標號以後的代碼將執行，由於在t r y塊和f i n a l l y塊中都沒有返回發生。這裏的代碼使函數返回5。並且，因爲中斷了從t r y塊到f i n a l l y塊的天然流程，可能要蒙受很大的性能損失（取決於運行程序的C P U）
*************************
=====================
寫上面的代碼是初步的，如今來看結束處理程序在咱們代碼裏面的真正的價值：
看代碼：（信號燈被正常釋放，reserve的一頁內存沒有被Free，安全性：安全）
DWORD TermHappenSomeError()
{
DWORD dwReturnValue = 9;
DWORD dwMemorySize = 1024;

char* lpAddress;
lpAddress = (char*)VirtualAlloc(NULL, dwMemorySize, MEM_RESERVE, PAGE_READWRITE);
finally塊的總結性說明
咱們已經明確區分了強制執行f i n a l l y塊的兩種狀況：
• 從t r y塊進入f i n a l l y塊的正常控制流。
• 局部展開：從t r y塊的過早退出（g o t o、l o n g j u m p、c o n t i n u e、b r e a k、r e t u r n等）強制控制轉移到f i n a l l y塊。
第三種狀況，全局展開（ global unwind），在發生的時候沒有明顯的標識，咱們在本章前面Func_SEHTerminate函數中已經見到。在Func_SEHTerminate的t r y塊中，有一個對TermHappenSomeError函數的調用。TermHappenSomeError函數會引發一個內存訪問違規（ memory access violation ），一個全局展開會使Func_SEHTerminate函數的f i n a l l y塊執行。
因爲以上三種狀況中某一種的結果而致使f i n a l l y塊中的代碼開始執行。爲了肯定是哪種狀況引發f i n a l l y塊執行，能夠調用內部函數AbnormalTermination：這個內部函數只在f i n a l l y塊中調用，返回一個B o o l e a n值。指出與f i n a l l y塊相結合的t r y塊是否過早退出。換句話說，若是控制流離開t r y塊並天然進入f i n a l l y塊，AbnormalTermination將返回FA L S E。若是控制流非正常退出t r y塊—一般因爲g o t o、r e t u r n、b r e a k或c o n t i n u e語句引發的局部展開，或因爲內存訪問違規或其餘異常引發的全局展開—對AbnormalTermination的調用將返回T R U E。沒有辦法區別f i n a l l y塊的執行是因爲全局展開仍是因爲局部展開。但這一般不會成爲問題，由於能夠避免編寫執行局部展開的代碼。（注意內部函數是編譯程序識別的一種特殊函數。編譯程序爲內部函數產生內聯（i n l i n e）代碼而不是生成調用函數的代碼。例如， m e m c p y是一個內部函數（若是指定/ O i編譯程序開關）。當編譯程序看到一個對m e m c p y的調用，它直接將m e m c p y的代碼插入調用m e m c p y的函數中，而不是生成一個對m e m c p y函數的調用。其做用是代碼的長度增長了，但執行速度加快了。
在繼續以前，回顧一下使用結束處理程序的理由：
• 簡化錯誤處理，因全部的清理工做都在一個位置而且保證被執行。
• 提升程序的可讀性。
• 使代碼更容易維護。
• 若是使用得當，具備最小的系統開銷。
異常處理程序
異常是咱們不但願有的事件。在編寫程序的時候，程序員不會想去存取一個無效的內存地址或用0來除一個數值。不過，這樣的錯誤仍是經常會發生的。C P U負責捕捉無效內存訪問和用0除一個數值這種錯誤，並相應引起一個異常做爲對這些錯誤的反應。C P U引起的異常，就是所謂的硬件異常（ hardware exception）。在本章的後面，咱們還會看到操做系統和應用程序也能夠引起相應的異常，稱爲軟件異常（ software exception）。
當出現一個硬件或軟件異常時，操做系統嚮應用程序提供機會來考察是什麼類型的異常被引起，並可以讓應用程序本身來處理異常。下面就是異常處理程序的語法：
__try
{
   file://保護塊
}
__except(異常過慮器)
{
  file://異常處理程序
}
注意__ e x c e p t關鍵字。每當你創建一個t r y塊，它必須跟隨一個f i n a l l y塊或一個e x c e p t塊。一個try 塊以後不能既有f i n a l l y塊又有e x c e p t塊。但能夠在t r y - e x c e p t塊中嵌套t r y - f i n a l l y塊，反過來也能夠。
異常處理程序代碼初步
與結束處理程序不一樣，異常過濾器（ exception filter）和異常處理程序是經過操做系統直接執行的，編譯程序在計算異常過濾器表達式和執行異常處理程序方面不作什麼事。下面幾節的內容舉例說明t r y - e x c e p t塊的正常執行，解釋操做系統如何以及爲何計算異常過濾器，並給出操做系統執行異常處理程序中代碼的環境。
原本想把代碼所有寫出來的，可是實在是寫這邊文擋化的時間太長了，因此接下來就只是作說明，並且try和except塊比較簡單。
儘管在結束處理程序的t r y塊中使用r e t u r n、g o t o、c o n t i n u e和b r e a k語句是被強烈地反對，但在異常處理程序的t r y塊中使用這些語句不會產生速度和代碼規模方面的不良影響。這樣的語句出如今與e x c e p t塊相結合的t r y塊中不會引發局部展開的系統開銷
當引起了異常時，系統將定位到e x c e p t塊的開頭，並計算異常過濾器表達式的值，過濾器表達式的結果值只能是下面三個標識符之一，這些標識符定義在windows的Except. h文件中。標識符定義爲：
EXCEPTION_CONTINUE_EXECUTION (–1)   Exception is dismissed. Continue execution at the point where the exception occurred.
EXCEPTION_CONTINUE_SEARCH (0)   Exception is not recognized. Continue to search up the stack for a handler, first for containing try-except statements, then for handlers with the next highest precedence.
EXCEPTION_EXECUTE_HANDLER (1)   Exception is recognized. Transfer control to the exception handler by executing the __except compound statement, then continue execution at the assembly instruction that was executing when the exception was raised.
下面將討論這些標識符如何改變線程的執行。
下面的流程歸納了系統如何處理一個異常的狀況：(這裏的流程假設是正向的)
*****開始 -> 執行一個CPU指令 -> {是否有異常被引起} -> 是 -> 系統肯定最裏層的try 塊 -> {這個try塊是否有一個except塊} -> 是 -> {過濾器表達式的值是什麼} ->異常執行處理程序 -> 全局展開開始 -> 執行except塊中的代碼 -> 在except塊以後執行繼續*****
EXCEPTION_EXECUTE_HANDLER
在異常過濾器表達式的值若是是EXCEPTION_EXECUTE_HANDLER，這個值的意思是要告訴系統：「我認出了這個異常。即，我感受這個異常可能在某個時候發生，我已編寫了代碼來處理這個問題，如今我想執行這個代碼。」在這個時候，系統執行一個全局展開，而後執行向except塊中代碼（異常處理程序代碼）的跳轉。在except塊中代碼執行完以後，系統考慮這個要被處理的異常並容許應用程序繼續執行。這種機制使windows應用程序能夠抓住錯誤並處理錯誤，再使程序繼續運行，不須要用戶知道錯誤的發生。可是，當except塊執行後，代碼將從何處恢復執行？稍加思索，咱們就能夠想到幾種可能性:
第一種可能性是從產生異常的CPU指令以後恢復執行。這看起來像是合理的作法，但實際上，不少程序的編寫方式使得當前面的指令出錯時，後續的指令不可以繼續成功地執行。代碼應該儘量地結構化，這樣，在產生異常的指令以後的CPU指令有望得到有效的返回值。例如，可能有一個指令分配內存，後面一系列指令要執行對該內存的操做。若是內存不可以被分配，則全部後續的指令都將失敗，上面這個程序重複地產生異常。所幸的是，微軟沒有讓系統從產生異常的指令以後恢復指令的執行。這種決策使咱們免於面對上面的問題。
第二種可能性是從產生異常的指令恢復執行。這是頗有意思的可能性。若是在except塊中
有這樣的語句會怎麼樣呢：在except塊中有了這個賦值語句，能夠從產生異常的指令恢復執行。這一次，執行將繼續，不會產生其餘的異常。能夠作些修改，讓系統從新執行產生異常的指令。你會發現這種方法將致使某些微妙的行爲。咱們將在EXCEPTION_CONTINUE_EXECUTION一節中討論這種技術。
第三種可能性是從except塊以後的第一條指令開始恢復執行。這實際是當異常過濾器表達式的值爲EXCEPTION_EXECUTE_HANDLER時所發生的事。在except塊中的代碼結束執行後，控制從except塊以後的第一條指令恢復。

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)最相近的
類裏。你能夠這樣說虛擬函數匹配採用最優匹配法，而異常處理匹配採用的是最早匹配法。

附：
異常的描述