异常与构造函数、析构函数

C++代码，发现异常没那么简单，使用须谨慎。

翻阅了《Effective C++》 《More Effective C++》《Inside The C++ Object Model》的相关章节，大概弄明白了一些东东，总结在本文。 

本文不是总结普适的C++异常机制，还没有这个内力哈！ 主要是结合构造函数和析构函数，来总结异常对他俩的影响。构造函数和析构函数本来就很折磨脑筋，再叠加上异常机制，确实比较复杂。 

异常与析构函数

本节内容较少，因此先说。构造函数放到下一节讨论。 

绝对不要将异常抛出析构函数

这一条在《Effective C++》 《More Effective C++》中均被作为独立章节讲解，可见其重要性。

有一点不要误解：析构函数的代码当然可以throw异常，只是这个异常不要被抛出析构函数之外。如果在析构函数中catch住异常，并且不再抛出，这就不会带来问题。 

至于原因，有两点。我们先看第一点。 

异常被抛出析构函数之外，往往意味着析构函数的工作没有做完。如果析构函数需要释放一些资源，异常可能导致资源泄露，使得程序处于一个不安全的状态。 

如下面的伪代码所示，异常导致p不能free，从而造成内存泄露。

class A
{
public:
    ~A()
   {
        throw exception;
        free(p);
   }
};

OK，这个问题好办，我好好写代码，确保析构函数释放所有的资源之后，才抛出异常。这还不行吗？

我们来看第二个原因。 

如果两个异常同时存在：第一个异常还没有被catch，第二个异常又被抛出，这会导致C++会调用terminate函数，把程序结束掉！

异常与构造函数

构造函数本来就是一件难以琢磨的东东，背后做了很多事情：成员对象的构造、基类成分的构造、虚表指针的设置等。这些事情本来就很纠结了，再让构造函数抛出异常，会出现怎样的悲剧呢？

有一点比较安慰：异常即使被抛出构造函数之外，也不会造成程序结束。那么，是否存在资源泄漏的问题呢？不可一概而论，我们分情况分析。