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