[翻译] Effective C++, 3rd Edition, Item 8: 防止因为 exceptions（异常）而离开 destructors（析构函数）

关注

翻译最新推荐文章于 2026-11-12 15:18:02 发布 3.9k 阅读 AI 写同款· GEO 优化 ›

基于OSPF技术的某企业网络设计（完整文档+ENSP拓扑图) 主要对网络规划与设计，以企业网络为背景，对某个中型企业网络进行规划设计，该企业总部在南京，在常州有一个分公司，需要实现总部和分公司能够访问外网，能够让分公司内的用户或主机访问总部服务器的资源，并且保证数据的安全性。在这次总部企业网络设计中，考虑到资金的问题，核心层部署2台核心三层交换机，负责转发总部内部用户的流量，并充当内部用户网关，能够实现内部不同网段的用户之间的连通性。对于一些对网络比较敏感的企业或用户，对网络的要求较高，对于网络的稳定性和安全性也有较高的要求。阅读详情

Item 8: 防止因为 exceptions（异常）而离开 destructors（析构函数）

作者：Scott Meyers

译者：fatalerror99 (iTePub's Nirvana)

发布：http://blog.youkuaiyun.com/fatalerror99/

C++ 并不禁止从 destructors（析构函数）中引发 exceptions（异常），但是它坚决地阻止这样的实践。至于有什么好的理由，考虑：

class Widget {
public:
...
~Widget() { ... } // assume this might emit an exception
};

void doSomething()
{
std::vector<Widget> v;
...
} // v is automatically destroyed here

当 vector v 被销毁时，它有责任销毁它包含的所有 Widgets。假设 v 中有十个 Widgets，在第一个的析构过程中，抛出一个 exception（异常）。其它 9 个 Widgets 仍然必须被销毁（否则它们持有的所有资源将被泄漏），所以 v 应该调用它们的 destructors（析构函数）。但是假设在这个调用期间，第二个 Widget 的 destructors（析构函数）又抛出一个 exception（异常）。现在同时有两个活动的 exceptions（异常），对于 C++ 来说，这太多了。在非常巧合的条件下产生这样两个同时活动的异常，程序的执行会终止或者引发 undefined behavior（未定义行为）。在本例中，将引发 undefined behavior（未定义行为）。使用任何其它的标准库 container（容器）（比如，list，set），任何 TR1（参见 Item 54）中的 container（容器），甚至是一个 array（数组），都可能会引发同样的 undefined behavior（未定义行为）。也并非必须是 containers（容器）或 arrays（数组）才会陷入麻烦。程序过早终止或 undefined behavior（未定义行为）是 destructors（析构函数）引发 exceptions（异常）的结果，即使没有使用 containers（容器）和 arrays（数组）也会如此。C++ 不喜欢引发 exceptions（异常）的 destructors（析构函数）。

这比较容易理解，但是如果你的 destructor（析构函数）需要执行一个可能失败而抛出一个 exception（异常）的操作，该怎么办呢？例如，假设你与一个数据库连接类一起工作：

class DBConnection {
public:
...

static DBConnection create();        // function to return
                                       // DBConnection objects; params
                                       // omitted for simplicity

void close(); // close connection; throw an
}; // exception if closing fails

为了确保客户不会忘记在 DBconnection objects（对象）上调用 close，一个合理的主意是为 DBConnection 建立一个 resource-managing class（资源管理类），在它的 destructor（析构函数）中调用 close。这样的 resource-managing classes（资源管理类）将在 Chapter 3（第三章）中一探究竟，但在这里，只要认为这样一个 class（类）的 destructor（析构函数）看起来像这样就足够了：

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 就可以了，但是如果这个调用导致一个 exception（异常），DBConn 的 destructor（析构函数）将传播那个 exception（异常），也就是说，它将离开 destructor（析构函数）。这就产生了问题，因为 destructor（析构函数）抛出了一个烫手的山芋。

有两个主要的方法避免这个麻烦。DBConn 的 destructor（析构函数）能：

Terminate the program if close tHRows（如果 close 抛出异常就终止程序），一般是通过调用 abort：

DBConn::~DBConn()
{
try { db.close(); }
catch (...) {
make log entry that the call to close failed;
std::abort();
}
}

如果在析构的过程遭遇到错误后程序不能继续运行，这就是一个合理的选择。它有一个好处是：如果允许从 destructor（析构函数）传播 exception（异常）可能会导致 undefined behavior（未定义行为），这样就能防止它发生。也就是说，调用 abort 就可以预先防止 undefined behavior（未定义行为）。

Swallow the exception arising from the call to close（抑制这个对 close 的调用造成的异常）：

DBConn::~DBConn()
{
try { db.close(); }
catch (...) {
make log entry that the call to close failed;
}
}

通常，swallowing exceptions（抑制异常）是一个不好的主意，因为它会隐瞒重要的信息—— something failed（某事失败了）！然而，有些时候，swallowing exceptions（抑制异常）比冒程序过早终止或 undefined behavior（未定义行为）的风险更可取。程序必须能够在遭遇到一个错误并忽略之后还能继续可靠地运行，这才能成为一个可行的选择。

这些方法都不太吸引人。它们的问题首先在于程序无法对引起 close 抛出 exception（异常）的条件做出回应。

一个更好的策略是设计 DBConn 的 interface（接口），以使它的客户有机会对可能会发生的问题做出回应。例如，DBConn 能够自己提供一个 close 函数，从而给客户一个机会去处理从那个操作中发生的 exception（异常）。它还能保持对它的 DBConnection 是否已被 closed 的跟踪，如果没有就在 destructor（析构函数）中自己关闭它。这样可以防止连接被泄漏。如果在 DBConnection（原文如此，严重怀疑此处应为 DBConn ——译者注）的 destructor（析构函数）中对 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 的 destructor（析构函数）移交给 DBConn 的客户（同时在 DBConn 的 destructor（析构函数）中包含一个“候补”调用）可能会作为一种肆无忌惮地推卸责任的做法而使你吃惊。你甚至可以把它看作对 Item 18 中关于使 interfaces（接口）易于正确使用的建议的违背。实际上，这都不正确。如果一个操作可能失败而抛出一个 exception（异常），而且可能有必要处理这个 exception（异常），这个 exception（异常）就 has to come from some non-destructor function（必须来自非析构函数）。这是因为 destructor（析构函数）引发 exception（异常）是危险的，永远都要冒着程序过早终止或 undefined behavior（未定义行为）的风险。在本例中，让客户自己调用 close 并不是强加给他们的负担，而是给他们一个时机去应付错误，否则他们将没有机会做出回应。如果他们找不到可用到机会（或许因为他们相信不会有错误真的发生），他们可以忽略它，依靠 DBConn 的 destructor（析构函数）为他们调用 close。如果一个错误恰恰在那时发生——如果由 close 抛出——如果 DBConn 抑制了那个 exception（异常）或者终止了程序，他们将无处诉苦。毕竟，他们无处着手处理问题，他们将不再使用它。