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

Prevent exceptions from leaving destructors

C++并不禁止析构函数吐出异常，但不鼓励你这样做。考虑以下代码：

class Widget{
public:
	...
	~Widget(){...}    //假设这个可能吐出一个异常
};
void doSomething()
{
	std::vector<Widget> v;   
	...
}                   //v在这里被自动销毁

当vector v被销毁，它有责任销毁其内含的所有Widgets。假设v内含十个Widgets，而在析构第一个元素期间，有个异常被抛出。其他九个Widgets还是应该被销毁（否则它们保存的任何资源都会发生泄露），因此v应该调用它们各个析构函数。但假设在那些调用期间，第二个Widget析构函数又抛出异常。现在有两个同时作用的异常，这对C++而言太多了。在两个异常同时存在的情况下，程序若不是结束执行就是导致不明确行为。本例中它会导致不明确行为。

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

class DBConnection {
public:
	...
	static DBConnection create();
	void close();     //失败抛出异常
};

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

class DBConn{
public:
	...
	~DBConn(){      //确保数据库总是被关闭
		db.close();
	}
};

如果close调用导致异常，DBConn析构函数会传播该异常，也就是允许它离开这个析构函数。有两个办法可以避免这个问题。DBConn的析构函数可以：

• 如果close抛出异常就结束程序，通常通过调用abort完成：

DBConn::~DBConn()
{
	try{ db.close(); }
	catch (...){
		std::abort();
	}
}

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

• 吞下因调用close而发生的异常

DBConn::~DBConn()
{
	try{ db.close(); }
	catch (...){

	}
}

一般而言，将异常吞掉是个坏主意，因为它压制了“某些动作失败”的重要信息？然而有时候吞下异常也比负担“草率结束程序”或“不明确行为带来的风险”好。

这些办法都没有什么吸引力。问题在于两者都无法对“导致close抛出异常”的情况做出反应。一个较佳的策略时重新设计DBConn接口，使其客户有机会对可能出现的问题作出反应。例如DBConn自己可以提供一个close函数，因而赋予客户一个机会得以处理异常。DBConn也可以追踪其所管理之DBConnection是否已被关闭，并在答案为否的情况下由其析构函数关闭。

class DBConn{
public:
	void close()
	{
		db.close();
		closed = true;
	}
	~DBConn(){      //确保数据库总是被关闭
		try{ db.close(); }
		catch (...){

		}
	}
private:
	DBConnection db;
	bool closed;
};

由客户自己调用close并不会对他们带来负担，而是给他们一个处理错误的机会，否则他们没机会响应。如果他们补任务这个机会有用。可以忽略它，依赖DBConn析构函数去调用close。

请记住

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