Item8: Prevent exceptions from leaving destructors

C++并不禁止析构函数吐出异常。但不鼓励你这么做。这是有理由的：

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，而在析构第一个元素期间，有个异常被抛出。其他九个Widgets还是应该被销毁（否则它们保存的任何资源都会发生泄漏），因此v应该调用它们各个析构函数。但假设在那些调用期间，第二个Widget析构函数又抛出异常。现在有两个同时作用的异常，这对C++而言太多了。在两个异常同时存在的情况下，程序若不是结束执行就是导致不明确行为（undefined behaviour）。本例中它会导致不明确的行为。使用标准程序库的任何其他容器（如list，set）或TR1的任何容器（见条款54）或甚至array，也会出现相同情况。容器或array并非遇上麻烦的必要条件，只要析构函数吐出异常，即使并非使用容器或arrays，程序也可能过早结束或出现不明确行为。是的，C++不喜欢析构函数吐出异常！

 

      但如果你的析构函数必须执行一个动作，而该动作可能会失败时抛出异常，该怎么办？

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对象身上调用close()，一个合理的想法就是创建一个用来管理DBConnection资源的class，并在其析构函数中调用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析构函数会传播该异常，如允许它离开这个析构函数。那就会造成问题，because destructors that throw mean trouble。

 

    两个解决办法：

    1、如果close抛出异常就结束程序。通常通过调用abort完成：

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

 

2、吞下因调用close而发生的异常（Swallow the exception arising from the call to close）：

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

 

一般而言，将异常吞掉是个坏主意，because it suppresses important information — something failed!

 

不过，这些办法都没有什么吸引力。

一个更佳策略是重新设计DBConn接口。使其用户有机会对可能出现的问题作出反应。如DBConn自己可以提供一个close函数，因而赋予用户一个机会得以处理“因该操作而发生的异常”。DBConn也可以追踪其所管理之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析构函数去调用close。如果真有错误发生——如果close的确抛出异常——而且DBConn吞下该异常或结束程序，用户也别抱怨，毕竟他们曾经有机会第一手处理问题，而他们选择了放弃。

 

请记住：

1、析构函数绝不要吐出异常。如果一个被析构函数调用的函数有可能抛出异常，析构函数应该捕捉任何异常，然后吞下它们（不传播）或结束程序。

2、如果用户需要对某个操作函数运行期间抛出的异常做出反应，那么class应该提供一个普通函数（而非在析构函数中）执行该操作。