[C++] 析构函数中的异常
1. 同时发生多个异常
C++并不禁止析构函数吐出异常，但它不鼓励你这样做。
这是有理由的，考虑以下代码：
class Widget{
public:
...
// 假设这个可能吐出一个异常
~Widget(){ ... }
};
void doSomething(){
std::vector<Widget> v;
// v在这里被自动销毁
}
当vector v被销毁，它有责任销毁其内涵的所有Widget，
假设v内含十个Widget，而在析构第一个元素期间，有个异常被抛出。
其它九个Widget还是应该被销毁（否则它们保存的任何资源都会发生泄漏），
因此，v应该调用它们各个析构函数。
但假设在那些调用期间，第二个Widget析构函数又抛出异常，
现在有两个同时作用的异常，这对C++而言太多了。
在两个异常同时存在的情况下，程序若不是结束执行就是导致不明确行为。
本例中，它会导致不明确的行为，
使用标准程序库的任何其他容器（如list，set），
或TR1的任何容易，或者甚至array，也会出现相同情况。
容器或array并非遇上麻烦的必要条件，只要析构函数吐出异常，
即使并非使用容器或array，程序也可能过早结束或出现不明确行为。
是的，C++不喜欢析构函数吐出异常。
2. 以对象管理资源
这很容易理解，但如果你的析构函数必须执行一个动作，而该动作可能会在失败时抛出异常，该怎么办？
举个例子，假设你使用一个class负责数据库连接：
class DBConnection{
public:
...
// 这个函数返回DBConnection对象
static DBConnection create();
// 关闭联机。失败则抛出异常
void close();
};
为确保客户不忘记在DBConnection对象身上调用close()，
一个合理的想法是创建一个用来管理DBConnection资源的class，并在其析构函数中调用close。
// 这个class用来管理DBConnection对象
class DBConn{
public:
...
// 确保数据库连接总是会被关闭
~DBConn(){
db.close();
}
private:
DBConnection db;
};
这便允许客户写出这样的代码：
// 开启一个区块（block）
{
// 建立DBConnection对象，并交给DBConn对象以便管理
DBConn dbc(DBConnection::create());
// 通过DBConn的接口，使用DBConnection对象
...
// 在区块结束点，DBConn对象被销毁
// 因而自动为DBConnection对象调用close
}
只要调用close成功，一切都美好，
但如果该调用导致异常，DBConn析构函数会传播该异常，也就是允许它离开这个析构函数。
那会造成问题，因为那就是抛出了难以驾驭的麻烦。
3. 结束程序 vs 吞下异常
两个办法可以避免这一问题，DBConn的析构函数可以。
（1）如果close抛出就结束程序，通常通过调用abort完成：
DBConn::~DBConn(){
try{
db.close();
}catch(...){
// 制作运转记录，记下对close的调用失败
...
std::abort();
}
}
如果程序遭遇一个“于析构期间发生的错误”后无法继续执行，“强迫结束程序”是个合理选项，
毕竟它可以阻止异常从析构函数传播出去（那会导致不明确的行为）。
也就是说调用abort可以抢先制“不明确行为”于死地。
（2）吞下因调用close而发生的异常：
DBConn::~DBConn(){
try{
db.close();
}catch(...){
// 制作运转记录，记下对close的调用失败
...
}
}
一般而言，将异常吞掉是个坏主意，因为它压制了“某些动作失败”的重要信息。
然而有时候吞下异常也比负担“草率结束程序”或“不明确行为带来的风险”好。
为了让这成为一个可行方案，程序必须能够继续可靠的执行，即使在遭遇并忽略一个错误之后。
这些办法都没什么吸引力，
问题在于两者都无法对“导致close抛出异常”的情况作出反应。
4. 给客户处理异常的机会
一个较佳的策略是重新设计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吞下该异常或结束程序，
客户没有立场抱怨，毕竟他们曾有机会一手处理问题，而他们选择了放弃。
总结
析构函数绝对不要吐出异常，如果一个析构函数调用的函数可能抛出异常，
析构函数应该捕捉任何异常，然后吞下它们（不传播）或结束程序。
如果客户需要对某个操作函数运行期间抛出的异常做出反应，那么class应该提供一个普通函数（而非在析构函数中）执行该操作。
