条款08 别让异常逃离析构函数：
假设在析构函数其中发生了异常，程序可能会过早结束或者导致不明白行为（异常从析构函数传播出去）
看代码：
#include <iostream>
using namespace std;
class DBConnection
{
public:
void close()
{
int i = 3;
int j = 0;
int k = i/j;
printf("%d
",k);
}
};
class DBConn
{
public:
DBConn()
{
}
/*
~DBConn()
{
db.close();
}
*/
//解决的方法1：强迫结束程序
~DBConn()
{
try
{
db.close();
}
catch(...)
{
abort();//假设一个程序遭遇一个“于析构期间发生的错误”后无法继续同意，强迫结束是个合理的选择。用abort阻止异常从析构函数传播出去
}
}
//解决的方法2：吞下异常
/*
~DBConn()
{
try
{
db.close();
}
catch (...)
{
//制作运转记录，记下对close的调用失败
}
}
*/
private:
DBConnection db;
};
int main()
{
DBConn dbc;
//dbc对象销毁时会自己主动调用DBConnection的close函数；仅仅要调用close成功，一切美好，可是假设该调用出现异常。DBConn析构函数
//会传播该异常。也就是同意它离开这个析构函数。会造成问题。
return 0;
}
/*
採用本来的析构函数：
执行程序。提示一个程序已经停止工作(感觉这里编译器优化到解决方式1了，自己主动做了处理)，假设不停止工作。也出现了不明白行为。
採用解决方式1：
执行程序，提示一个debug error，终止程序。
採用解决方式2：
执行程序，程序执行通过。可是也不会打印k的值
*/
上面的解决方式1和2。都导致对close抛出的异常无法处理：
最佳办法就是DBConn自己又一次设计一个close接口，使得程序猿能够自己调用：
#include <iostream>
using namespace std;
class DBConnection
{
public:
void close()
{
int i = 3;
int j = 0;
int k = i/j;
printf("%d
",k);
}
};
class DBConn
{
public:
DBConn()
{
}
~DBConn()
{
if (!closed)
{
try //关闭连接。假设客户不那么做的话
{
db.close()
}
catch(...)
{
//在这里结束程序或者吞下异常
}
}
}
void close()
{
db.close();
closed = true;
}
private:
DBConnection db;
bool closed;
};
int main()
{
DBConn dbc;
//dbc对象销毁时会自己主动调用DBConnection的close函数；仅仅要调用close成功，一切美好，可是假设该调用出现异常，DBConn析构函数
//会传播该异常，也就是同意它离开这个析构函数。会造成问题。
return 0;
}
/*
这种方法把调用close的责任从DBConn析构函数手上移动到DBConn客户手上（但DBConn析构函数仍含有一个“双保险”调用）.
假设某个操作可能在失败时抛出异常。而又存在某种须要必须处理该异常，那么这个异常必须来自析构函数以外的某个函数
由于析构函数吐出异常，总会带来“过早结束程序”或者“发生不明白行为”的风险。
这里由客户自己调用close函数。假设发现异常，能够处理。
总结:
1:析构函数绝对不要吐出异常，假设一个被析构函数调用的函数可能抛出异常，析构函数应该捕捉该异常，然后吞下它们（不传播）或结束程序
2:假设客户须要对某个操作函数执行期间抛出的异常做出反应，那么class应该提供一个普通函数（而非析构函数）执行该操作。
*/
1:析构函数绝对不要吐出异常。假设一个被析构函数调用的函数可能抛出异常，析构函数应该捕捉该异常。然后吞下它们（不传播）或结束程序
2:假设客户须要对某个操作函数执行期间抛出的异常做出反应，那么class应该提供一个普通函数（而非析构函数）执行该操作。