很多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异常
}

综上所述，把一个对象传递给函数或一个对象调用虚拟函数与把一个对象做为异常抛出，这之间有三个主要区别.

第一、异常对象在传递时总被进行拷贝；当通过传值方式捕获时，异常对象被拷贝了两次.

对象做为参数传递给函数时不需要被拷贝.

第二、对象做为异常被抛出与做为参数传递给函数相比，前者类型转换比后者要少（前者只有两种转换形式）.

最后一点，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如下：

• 首先检查是否有一个调试程序与发生exception的进程联系在一起，推算这个调试程序是否有能力处理
• 如上面不能完成，操作系统就在发生exception event的线程中search exception event handler
• search与进程关联在一起的调试程序
• 系统执行自己的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://结束处理程序
}

在上面的代码段中，操作系统和编译程序共同来确保结束处理程序中的__finally代码块能够被执行，不管保护体（try块）是如何退出的。

不论你在保护体中使用return，还是goto，或者是longjump，结束处理程序（finally块）都将被调用。

我们来看一个实列：（返回值：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(异常过虑器)
{
     //异常处理程序
}

注意__except关键字。每当你建立一个try块，它必须跟随一个finally块或一个except块。一个try块之后不能既有finally块又有except块。但可以在try-except块中嵌套try-finally块，反过来也可以。
异常处理程序代码初步
与结束处理程序不同，异常过滤器（exceptionfilter）和异常处理程序是通过操作系统直接执行的，编译程序在计算异常过滤器表达式和执行异常处理程序方面不做什么事。

下面几节的内容举例说明try-except块的正常执行，解释操作系统如何以及为什么计算异常过滤器，并给出操作系统执行异常处理程序中代码的环境。

本来想把代码全部写出来的，但是实在是写这边文挡化的时间太长了，所以接下来就只是做说明，而且try和except块比较简单。

尽管在结束处理程序的try块中使用return、goto、continue和break语句是被强烈地反对，但在异常处理程序的try块中使用这些语句不会产生速度和代码规模方面的不良影响。

这样的语句出现在与except块相结合的try块中不会引起局部展开的系统开销.

当引发了异常时，系统将定位到except块的开头，并计算异常过滤器表达式的值，过滤器表达式的结果值只能是下面三个标识符之一，这些标识符定义在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块之后的第一条指令恢复。

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)  //临时对象的拷贝
{
     ...
}

catch(A& w)  // 捕获异常
{
     　// 处理异常
     　throw; // 重新抛出异常，让它继续传递
}
catch(A& w)  // 捕获Widget异常
{
     　// 处理异常
     　throw w; // 传递被捕获异常的拷贝
}