异常与构造函数、析构函数
转自：
异常与构造函数、析构函数
写Java代码的时候，遇到错误总是喜欢抛出异常，简单实用。最近开始写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);
- }
- };
class A
{
public:
~A()
{
throw exception;
free(p);
}
};
OK，这个问题好办，我好好写代码，确保析构函数释放所有的资源之后，才抛出异常。这还不行吗？
- class A
- {
- public:
- ~A()
- {
- free(p);
- throw exception;
- }
- };
class A
{
public:
~A()
{
free(p);
throw exception;
}
};
嗯，确实不行。我们来看第二个原因。
如果两个异常同时存在：第一个异常还没有被catch，第二个异常又被抛出，这会导致C++会调用terminate函数，把程序结束掉！
这简直是灾难，远比资源泄漏要严重。
那么，什么时候会同时出现两个异常呢？看下面的代码。
- void f()
- {
- A a; // 没错，就是前面的class A
- throw exception;
- }
void f()
{
A a; // 没错，就是前面的class A
throw exception;
}
f()抛出异常后，会进行stack-unwinding。在这个过程中，会析构所有的active local object。所谓active local object，就是已经构造完成的局部对象，例如上面的对象a。
调用a的析构函数时，（第一个）异常还没有被catch。可是a的析构函数也抛出了（第二个）异常。这时，两个异常同时存在了。程序会毫不留情地结束！
这个理由足够充分了：再也不要让异常逃离你的析构函数！
异常与构造函数
构造函数本来就是一件难以琢磨的东东，背后做了很多事情：成员对象的构造、基类成分的构造、虚表指针的设置等。这些事情本来就很纠结了，再让构造函数抛出异常，会出现怎样的悲剧呢？
有一点比较安慰：异常即使被抛出构造函数之外，也不会造成程序结束。那么，是否存在资源泄漏的问题呢？不可一概而论，我们分情况分析。
对象自身的内存如何释放
对象有可能在栈上，也可能在堆上，我们分两种情况讨论。
- // 对象在栈上
- f()
- {
- A a;
- }
- // 对象在堆上
- f()
- {
- A * a = new A();
- }
// 对象在栈上
f()
{
A a;
}
// 对象在堆上
f()
{
A * a = new A();
}
如果对象是在栈上，那么函数退栈自然会释放a占用的空间，无需多虑。
如果对象是在堆上，我们还得两种情况讨论：
- 如果是new运算符抛出的异常，那么堆空间还没有分配成功，也就无需释放
- 如果是构造函数抛出的异常，堆空间已经分配成功，那么编译器会负责释放堆空间（Inside The C++ Object Model, p301）
可见，对象本身的内存，是不会泄露的。
成员对象和基类成分怎么办
成员对象和基类成分的内存，会随着对象自身内存的释放而被一起释放，没什么问题。
但是，有一点需要谨记：如果一个对象的构造函数抛出异常，那么该对象的析构函数不会被调用。
原因很简单：如果对象没有被构造完整，析构函数中的某些代码可能会有风险。为了避免这类意外问题，编译器拒绝生成调用析构函数的代码。
那么，成员对象的基类成员对象的析构函数，会被调用吗？如果不会调用，则可能出现资源泄漏。答案是，会被调用。见下面的代码。
- class B : class C
- {
- A a;
- A * pa;
- public:
- B()
- {
- pa = new A();
- }
- ~B()
- {
- delete pa;
- }
- };
class B : class C
{
A a;
A * pa;
public:
B()
{
pa = new A();
}
~B()
{
delete pa;
}
};
如果B的构造函数抛出异常，编译器保证：成员对象a的析构函数、基类C的析构函数会被调用（Inside The C++ Object Model, p301）。
成员指针怎么办
注意上述代码中的pa，它指向一块堆空间，由于B的析构函数不会被调用了，内存就会出现泄漏。
这还真是一个问题，编译器也不能帮我们做更多事情，只能由程序员自己负责释放内存。
我们可能要这样写代码
- class B : class C
- {
- A a;
- A * pa;
- public:
- B()
- {
- pa = new A();
- try {
- throw exception;
- } catch(...)
- {
- delete pa; //确保释放pa
- throw;
- }
- }
- ~B()
- {
- delete pa;
- }
- };
class B : class C
{
A a;
A * pa;
public:
B()
{
pa = new A();
try {
throw exception;
} catch(...)
{
delete pa; //确保释放pa
throw;
}
}
~B()
{
delete pa;
}
};
这样的代码难看很多，有一种建议的做法就是：用智能指针包装pa。智能指针作为B的成员对象，其析构函数是可以被自动调用的，进而释放pa。
析构函数如何被自动调用
上面提到：
- 普通函数抛出异常时，所有active local object的析构函数都会被调用
- 构造函数抛出异常时，所有成员对象以及基类成分的析构函数都会被调用
那么，这是怎么实现的呢？
我们以第一种情况为例，分析实现细节。看下面的代码：
- f()
- {
- A a1;
- if (...) { // 某些条件下，抛出异常
- throw exception;
- }
- A a2;
- throw exception; // 总会抛出异常
- }
f()
{
A a1;
if (...) { // 某些条件下，抛出异常
throw exception;
}
A a2;
throw exception; // 总会抛出异常
}
如果L5抛出异常，那么对象a1会被析构。如果L8抛出异常，那么对象a1 a2都要被析构。编译器是怎么知道，什么时候该析构哪些对象的呢？
支持异常机制的编译器，会做一些”簿记“工作，将需要被析构的对象登记在特定的数据结构中。编译器将上述代码分成不同的区段，每个区段中需要被析构的对象，都不相同。
例如，上述代码中，L3 L4~L7 L8就是三个不同的区段：
- 如果L3抛出异常，那么没有对象需要析构
- 如果L4~L7抛出异常，那么a1需要被析构
- 如果L8抛出异常，那么a1和a2都要析构
编译器通过分析代码，簿记这些区段以及需要析构的object list。运行时，根据异常抛出时所在的区段，查找上述的数据结构，就可以知道哪些对象需要被析构。
构造函数抛出异常时，成员对象及基类成分被析构的原理，是类似的。在C++运行时看来，构造函数只是普通的函数而已。
总结
C++的异常机制，给编译器和运行时均带来了一定的复杂度和代价。上述的”簿记“工作，只是冰上一角。
关于异常的使用，也有很多坑。怎么throw 怎么catch，都是有讲究的。有空下次再做总结。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. 抛出异常
1.1 抛出异常（也称为抛弃异常）即检测是否产生异常，在C++中，其采用throw语句来实现，如果检测到产生异常，则抛出异常。
该语句的格式为： throw 表达式;
如果在try语句块的程序段中（包括在其中调用的函数）发现了异常，且抛弃了该异常，则这个异常就可以被try语句块后的某个catch语句所捕获并处理，捕获和处理的条件是被抛弃的异常的类型与catch语句的异常类型相匹配。由于C++使用数据类型来区分不同的异常，因此在判断异常时，throw语句中的表达式的值就没有实际意义，而表达式的类型就特别重要。
1.2 抛出异常实际是作为另一种返回值来使用的。 抛出异常的好处一是可以不干扰正常的返回值，另一个是调用者必须处理异常，而不像以前c语言返回一个整数型的错误码，调用者往往将它忽略了。
1.3 举例说明
假如说A方法掉调用-->B方法调用-->C方法。 然后在B和C方法里定义了throws Exception。A方法里定义了Try Catch。
那么调用A方法时，在执行到C方法里出现了异常，那么这个异常就会从C抛到B，再从B抛到A。在A里的try catch就会捕获这个异常，然后你就可以在catch写自己的处理代码。
那么为什么当时出现了异常不去处理呢？ 因为你业务逻辑调用的是A方法，你执行了A方法，当然要在A里得到异常，然后来处理。如果在C里面就处理异常，这就破坏程序结构了。 另外，A调用了C方法，假如还接着也调用了D,E,F方法，假如他们都有可能抛出异常，你说是在A里面获得处理一次好，还是在C,D,E,F得到了异常，每个都当时处理一下的好？ 当时就处理异常理论上也是可以的，而且大多数时候，到底在哪处理异常，是要根据需求和项目的具体情况的。
2. 构造函数可以抛出异常。
3. C++标准指明析构函数不能、也不应该抛出异常。
C++异常处理模型是为C++语言量身设计的，更进一步的说，它实际上也是为C++语言中面向对象而服务的。C++异常处理模型最大的特点和优势就是对C++中的面向对象提供了最强大的无缝支持。那么如果对象在运行期间出现了异常，C++异常处理模型有责任清除那些由于出现异常所导致的已经失效了的对象(也即对象超出了它原来的作用域)，并释放对象原来所分配的资源， 这就是调用这些对象的析构函数来完成释放资源的任务，所以从这个意义上说，析构函数已经变成了异常处理的一部分。
上面的论述C++异常处理模型它其实是有一个前提假设——析构函数中是不应该再有异常抛出的。试想，如果对象出了异常，现在异常处理模块为了维护系统对象数据的一致性，避免资源泄漏，有责任释放这个对象的资源，调用对象的析构函数，可现在假如析构过程又再出现异常，那么请问由谁来保证这个对象的资源释放呢?而且这新出现的异常又由谁来处理呢?不要忘记前面的一个异常目前都还没有处理结束，因此这就陷入了一个矛盾之中，或者说无限的递归嵌套之中。所以C++标准就做出了这种假设，当然这种假设也是完全合理的，在对象的构造过程中，或许由于系统资源有限而致使对象需要的资源无法得到满足，从而导致异常的出现，但析构函数完全是可以做得到避免异常的发生，毕竟你是在释放资源呀!
假如无法保证在析构函数中不发生异常，怎么办? 虽然C++标准中假定了析构函数中不应该，也不永许抛出异常的。但实际的软件系统开发中是很难保证到这一点的。所有的析构函数的执行过程完全不发生一点异常，这根本就是天方夜谭，或者说自己欺骗自己算了。而且有时候析构一个对象(释放资源)比构造一个对象还更容易发生异常，例如一个表示引用记数的句柄不小心出错， 结果导致资源重复释放而发生异常，当然这种错误大多时候是由于程序员所设计的算法在逻辑上有些小问题所导致的，但不要忘记现在的系统非常复杂，不可能保证 所有的程序员写出的程序完全没有bug。因此杜绝在析构函数中决不发生任何异常的这种保证确实是有点理想化了。
3.1 more effective c++提出两点理由（析构函数不能抛出异常的理由）：
1）如果析构函数抛出异常，则异常点之后的程序不会执行，如果析构函数在异常点之后执行了某些必要的动作比如释放某些资源，则这些动作不会执行，会造成诸如资源泄漏的问题。
2）通常异常发生时，c++的机制会调用已经构造对象的析构函数来释放资源，此时若析构函数本身也抛出异常，则前一个异常尚未处理，又有新的异常，会造成程序崩溃的问题。
3.2 那么当无法保证在析构函数中不发生异常时， 该怎么办?
其实还是有很好办法来解决的。那就是把异常完全封装在析构函数内部，决不让异常抛出函数之外。这是一种非常简单，也非常有效的方法。
~ClassName()
{
try{
do_something();
}
catch(){ //这里可以什么都不做，只是保证catch块的程序抛出的异常不会被扔出析构函数之外。
}
}
3.3 析构函数中抛出异常时概括性总结
1）C++中析构函数的执行不应该抛出异常；
2）假如析构函数中抛出了异常，那么你的系统将变得非常危险，也许很长时间什么错误也不会发生；但也许你的系统有时就会莫名奇妙地崩溃而退出了，而且什么迹象也没有，崩得你满地找牙也很难发现问题究竟出现在什么地方；
3）当在某一个析构函数中会有一些可能（哪怕是一点点可能）发生异常时，那么就必须要把这种可能发生的异常完全封装在析构函数内部，决不能让它抛出函数之外（这招简直是绝杀！呵呵！）；
4）一定要切记上面这几条总结，析构函数中抛出异常导致程序不明原因的崩溃是许多系统的致命内伤！