1 析构函数绝对不要突出异常。如果一个被析构函数调用的函数可能抛出异常,析构函数应该捕捉任何异常,然后吞下它们(不传播)或结束程序。
2 如果客户需要对某个操作函数运行期间抛出的异常做出反应,那么class应该提供一个普通函数(而非在析构函数中)执行该操作。
例:数据库连接类
class DBConnection{
public:
...
static DBConnection create();
void close(); //关闭联机,失败则抛出异常
};
为了确保客户不忘调用close(),一个合理的想法是创建一个用来管理DBConnection资源的类,并在其析构函数中调用close。
class DBConn{
public:
...
~DBConn()
{
db.close();
}
private:
DBConnection db;
};
这边允许客户写出这样的代码:
{
DBConn dbc(DBConnection::create())
... //在区块结束点,DBConn被销毁,自动调用db.close()
}
只要调close成功,一切美好。但如果导致异常,DBConn析构函数会传播该异常,也就是允许它离开这个析构函数。
那会抛出难以驾驭的麻烦,导致不明确的行为。
两个办法可以避免这一问题:
(1)如果close抛出异常就结束程序,通过调用abort:
DBConn::~DBConn()
{
try{db.close();}
catch(...){
制作运转记录,几下对close的调用失败;
std::abort();
}
}
(2)吞下异常:
DBConn::~DBConn()
{
try{db.close();}
catch(...){
制作运转记录,几下对close的调用失败;
}
}
一般情况下吞下异常压制了“某些动作失败”的重要信息,并不是一个好主意。但是可以让程序继续可靠的执行,即使在遭遇并忽略一个错误之后。
但是以上的2种方法都无法对抛出异常做出反应。较佳的策略是重新设计接口,使客户有机会对可能出现的问题做出反应。
class DBConn{
public:
...
void close()
{
db.close();
closed = true;
}
~DBConn()
{
if(!closed){
try{db.close();}
catch(...){
...记录下来或结束程序或吞下异常。
}
}
}
private:
DBConnection db;
bool closed;
};
以上代码可见把调用close的责任从DBConn析构函数手上转移到客户手上(但DBConn析构函数仍内含一个双保险调用)。
如果客户不自己调用处理close,在析构函数抛出异常时客户就没有立场抱怨,毕竟他们有机会第一手处理问题,而他们选择了放弃。