条款08: 别让异常逃离析构函数

结论：

• 析构函数绝对不要吐出异常。如果一个被析构函数调用的函数可能抛出异常。析构函数应该捕捉任何异常，然后吞下它们（不转播）或结束程序。
• 如果客户需要对某个操作函数运行期间抛出的异常做出反应，那么class应该提供一个普通函数（而非在析构函数中）执行该操作。

C++不喜欢析构函数吐出异常。但如果你的析构函数必须执行一个动作，该动作可能会在失败时抛出异常，该怎么办？举个例子，假设你使用一个class负责数据库连接：

class DBConnection 
{
public:
	...
	static DBConnection create();		// 这个函数返回DBConnection对象
	void close();						// 关闭联机：失败则抛出异常
}

为了确保客户不忘记在DBConnection对象身上调用close(),一个合理的想法时创建一个用来管理DBConnection资源的class，并在其析构函数中调用close。

class DBConn		// 这个class用来管理DBConnection对象
{
public:
	...
	~DBConn()
	{
		db.close();	// 确保数据库连接总是会被关闭
	}
private:
	DBConnection db;
}

这便允许客户写出这样的代码：

{										// 开启一个区块
DBConn dbc(DBConnection::create()); 	// 建立DBConnection对象并
										// 交给DBConn对象以便管理
...										// 通过DBConn接口，使用DBConnection对象
}										// 在区块结束点，DBConn对象被销毁，因而自动为
										// DBConnection对象调用close

只要调用close成功，一切都美好。但如果调用导致异常，DBConn析构函数会传播该异常，也就是允许它离开这个析构函数。那会造成问题，因为造成了难以驾驭的麻烦。
有两个解决方案可以避免这一问题。

方案一：通过abort结束程序。

DBConn::～DBConn()
{
	try {db.close();}
	catch(...) {
		制作运转记录，记下对close的调用失败；
		std::abort();
	}
}

如果程序遭遇一个“于析构期间发生的错误”后无法继续执行，“强迫结束程序”是个合理选项。毕竟它可以阻止异常从析构函数传播出去（那会导致不明确的行为）。也就是调用abort可以抢先制“不明确行为”于死地。

方案二：吞下因调用close而发生的异常。

DBConn::~DBConn()
{
	try {db.close();}
	catch (...) {
		制作运转记录，记下对close的调用失败；
	}
}

一般而言，将异常吞掉时坏主意，因为它压制了“某些动作失败”的主要信息！然而有些时候吞下异常液笔负担“草率结束程序”或“不明确行为带来的风险”好。为了让这成为一个可行的方案，程序必须可靠地执行，即使在遭遇并忽略一个错误之后。

这些办法都没什么吸引力。问题在于两者都无法对“导致close抛出异常”的情况做出反应。

最佳策略：“双保险”策略

一个最佳策略时重新设计DBConn接口，使其客户有机会对可能出现的问题做出反应。例如DBConn自己可以提供一个close函数，因为赋予客户一个机会得以“因该操作而发生的异常”。DBConn也可以跟踪其管理之DBConnection事都已被关闭，并在答案为否的情况下由其析构函数关闭之。这可以防止遗失数据库连接。然而如果DBConnection析构函数调用close失败，我们又将退回“强迫结束程序”或“吞下异常”的老路：

class DBConn
{
public:
	...
	void close()		// 供客户使用的新函数
	{
		db.close();
		closed = true;
	}
	～DBConn()
	{
		if (!closed) {
			try {db.close();}	// 关闭连接
			catch(...) {						// 如果关闭动作失败
				制作运转记录，记下对close的调用失败	// 记录下来并结束程序
				...								// 或吞下异常
			}
		}
	}
private:
	DBConnection db;
	bool closed;
}

把调用close的责任从DBConn析构函数手上移到DBConn客户手上（但DBConn析构函数仍含一个“双保险”调用）可能会给你“肆无忌惮转移负担”的印象。实际上这项污名不成立。**如果某个操作可能在失败时抛出异常，而又在某种需要必须处理该异常，那么这个异常必须来自析构函数以外的某个函数。**因为析构函数吐出异常就是危险，总会带来“过早结束程序”或“发生不明确行为”的风险。本例要说的是，由客户自己调用close并不会对他们来带负担，而是给他们一个处理错误的机会，否则它们没机会响应。如果我们不认为这个机会有用，可以忽略它，依赖DBConn析构函数去调用close。如果真有错误发生——如果close的确抛出异常——而且DBConn吞下该异常或结束程序，客户没有立场抱怨，毕竟它们曾有机会第一手处理问题，而它们选择了放弃。

（个人觉得这个最佳策略双保险就是把异常套了个娃，感觉不到有什么意义啊，甚至可以套n层，不知道各位看官怎么看？）