C++箴言：防止异常离开析构函数
添加时间: 2006-2-12 9:29:14 作者: C++教程 阅读次数:108 来源: http://www.d9soft.com
为了确保客户不会忘记调用 DBconnection 对象的 close，一个合理的主意是为 DBConnection 建立一个资源管理类，在它的析构函数中调用 close。这样的资源管理类将在以后的文章中探讨，但在这里，只要认为这样一个类的析构函数看起来像这样就足够了：
class DBConn { // class to manage DBConnection
public: // objects
...
~DBConn() // make sure database connections
{ // are always closed
db.close();
}
private:
DBConnection db;
};
它允许客户像这样编程：
{
// open a block
DBConn dbc(DBConnection::create()); // create DBConnection object
// and turn it over to a DBConn
// object to manage
... // use the DBConnection object
// via the DBConn interface
} // at end of block, the DBConn
// object is destroyed, thus
// automatically calling close on
// the DBConnection object
既然能成功地调用 close 那就好了，但是如果这个调用导致了异常，DBConn 的析构函数将散播那个异常，也就是说，它将离开析构函数。这就产生了问题，因为析构函数抛出了一个烫手的山芋。
有两个主要的方法避免这个麻烦。DBConn 的析构函数能：
终止程序 如果 close 抛出异常，调用 abort。
DBConn::~DBConn()
{
try { db.close(); }
catch (...) {
make log entry that the call to close failed;
std::abort();
}
}
如果程序在析构过程遭遇到错误后不能继续运行，这就是一个合理的选择。它有一个好处是：如果允许从析构函数散播异常可能会引起未定义行为，这样就能防止它发生。也就是说，调用 abort 就预先防止了未定义行为。
抑制这个异常 起因于调用 close：
DBConn::~DBConn()
{
try { db.close(); }
catch (...) {
make log entry that the call to close failed;
}
}
通常，抑制异常是一个不好的主意，因为它会隐瞒重要的信息——某些事情失败了！可是，有些时候，抑制异常比冒程序夭折或未定义行为的风险更可取。程序必须能够在遭遇到错误并忽略之后还能继续可靠地执行，这才能成为一个可行的选择。
这些方法都不太吸引人。它们的问题在于程序无法在第一现场对引起 close 抛出异常的条件做出回应。
一个更好的策略是设计 DBConn 的接口，以使它的客户有机会对可能会发生的问题做出回应。例如，DBConn 能够自己提供一个 close 函数，从而给客户一个机会去处理从那个操作中发出的异常。它还能保持对它的 DBConnection 是否已被关闭的跟踪，如果没有关闭就在析构函数中自己关闭它。这样可以防止连接被泄漏。如果在 DBConnection 的析构函数中调用 close 失败，无论如何，我们还可以再返回到终止或者抑制。
class DBConn {
public:
...
void close() // new function for
{
// client use
db.close();
closed = true;
}
~DBConn()
{
if (!closed) {
try { // close the connection
db.close(); // if the client didn’t
}
catch (...) { // if closing fails,
make log entry that call to close failed; // note that and
... // terminate or swallow
}
}
private:
DBConnection db;
bool closed;
};
将调用 close 的责任从 DBConn 的析构函数转移到 DBConn 的客户（同时在 DBConn 的析构函数中包含一个“候补”调用）可能会作为一种肆无忌惮地推卸责任的做法而刺激你。你甚至可以把它看作一个忠告（使接口易于正确使用）的违背。实际上，这都不正确。如果一个操作可能失败而抛出一个异常，而且可能是一个需要处理的异常，这个异常就必须来自非析构函数。这是因为析构函数引发异常是危险的，永远都要冒着程序夭折或未定义行为的风险。在此例中，让客户调用 close 并不是强加给他们的负担，而是给他们一个时机去应付错误，否则他们将没有机会做出回应。如果他们找不到可用到机会（或许因为他们相信不会有错误真的发生），他们可能忽略它，依靠 DBConn 的析构函数为他们调用 close。如果一个错误恰恰发生在那时——如果由 close 抛出——如果 DBConn 抑制了那个异常或者终止了程序，他们将无处诉苦。毕竟，他们无处着手处理问题，他们将不再使用它。
Things to Remember
·析构函数应该永不引发异常。如果析构函数调用了可能抛出异常的函数，析构函数应该捕捉任何异常，然后抑制它们或者终止程序。
·如果类客户需要能对一个操作抛出的异常做出回应，则那个类应该提供一个常规的（非析构函数）函数来完成这个操作。
上一篇文章: C++箴言:让=返回一个*this的引用 下一篇文章: C#编程实现Excel文档中搜索文本
相关文章: