C++并不禁止析构函数吐出异常,但它不鼓励这样做。这是有理由的。考虑以下代码:
class Widget{
public:
~Widget() {//假设这个可能抛出一个异常
}
};
void doSomething()
{
std::vector<Widget> v;
} // v 在这里被自动销毁
当vector v被销毁,它有责任销毁其内含的所有Widgets。假设v内含十个Widget,而在析构第一个元素期间,有个异常被抛出。其他九个Widget还是应该被销毁(否则它们保存的任何资源都会发生泄露),因此v应该调用它们各个析构函数。但假设在那些调用期间,第二个Widget析构函数又抛出异常。现在有两个同时作用的异常,这对C++而言太多了。在两个异常同时存在的情况下,程序若不是结束执行就是导致不明确行为。
使用标准库的任何其他容器(如list,set)或甚至array,也会出现相同情况。只要析构函数抛出异常,即使并非使用容器或array,程序也可能过早结束或出现不明确行为。
这容易理解,但如果你的析构函数必须执行一个动作,而该动作可能会在失败时抛出异常,该怎么办?假设使用一个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;
};
这便允许客户写出这样的代码:
{//开启一个block
DBConn dbc(DBConnection::create());//建立DBConnection对象并交给DBConn对象以便管理
//...
//通过DBConn的接口使用DBConnection对象
//...
}//在block结束后后,DBConn对象被销毁,因而自动为DBConnection对象调用close
只要调用close成功,一切都很美好,但如果该调用导致异常,DBConn析构函数会传播该异常,也就是允许它离开这个析构函数。那会造成问题,因为那就是抛出了难以驾驭的麻烦。
两个办法以避免这一问题。DBConn的析构函数可以:
1.如果close抛出异常就结束程序。通常通过调用abort完成:
DBConn::~DBConn() //确保数据库连接总是会被关闭
{
try {
db.close();
}
catch (...) {
//制作运作记录,记下对close的调用失败
std::abort();//如果close抛出异常就结束程序
}
}
如果程序遭遇一个”于析构期间发生的错误“后无法继续执行,”强迫结束程序“是个合理选项。毕竟它可以阻止异常从析构函数传播出去(那会导致不明确的行为)。也就是说调用abort可以抢先制”不明确行为“于死地。
2.吞下因调用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 {//关闭连接(如果提供给客户使用的close函数没有调用的话)
db.close();
}
catch (...) {
//制作运作记录,记下对close的调用失败
//结束程序或吞下异常
//std::abort();//如果close抛出异常就结束程序
}
}
}
private:
DBConnection db;
bool closed;
};
把调用close的责任从DBConn析构函数手上移到DBConn客户手上(但DBConn析构函数仍内含一个”双保险“调用)可能会给你”肆无忌惮转移负担“的印象。
如果某个操作可能在失败时抛出异常,而又存在某种需要必须处理该异常,那么这个异常必须来自析构函数以外的某个函数。因为析构函数吐出异常就是危险,总会带来”过早结束程序“或”发生不明确行为“的风险。本例要说的是,由客户自己调用close并不会对他们带来负担,而是给他们一个处理错误的机会,否则他们没机会响应。如果用户不认为这个机会有用,可以忽略它,依赖DBConn析构函数去调用close。如果真有错误发生——如果close的确抛出异常——而且DBConn吞下该异常或结束程序,客户没有立场抱怨,毕竟他们曾有机会第一手处理问题,而他们选择了放弃。
要点:
1.析构函数绝对不要抛出异常。如果一个被析构函数调用的函数可能抛出异常,析构函数应该捕捉任何异常,然后吞下它们(不传播)或结束程序。
2.如果客户需要对某些函数运行期间抛出的异常做出反应,那么class应该提供一个普通函数(而非在析构函数中)执行该操作。