条款8 别让异常逃离析构函数
记住:
★析构函数绝对不要吐出异常。若一个被析构函数调用的函数可能抛出异常,析构函数应该捕捉任何异常,然后吞下它们(不传播)或结束程序。
★若客户需对某个操作函数运行期间抛出的异常做出反应,那么class应提供一个普通函数(而非在析构函数)执行该操作。
-----------------------------------------------------------------------------------------------------------------------------------------
问题背景:
1 class Widget { 2 public: 3 ... 4 ~Widget() {...} //假设这个可能吐出一个异常 5 }; 6 7 void doSomething() { 8 std::vector<Widget> v; 9 ... 10 }
当容器v被销毁时,其有责任销毁其内含的所有Widgets。假设v内含十个Widgets,而在析构第一个元素期间,有个异常被抛出,此时其他九个Widgets还是应该被销毁,因此v应该调用它们各个析构函数。但假设在那些调用期间,第二个Widget析构函数又抛出异常。现在有两个同时作用的异常,在此情况下,程序若不是结束执行就是导致不明确行为!!!
若你的析构函数必须执行一个动作,而该动作可能会抛出异常,该怎么办?举例如下:
1 class DBConnection { //此类负责数据库连接 2 3 public: 4 ... 5 static DBConnection create(); 6 void close(); //关闭数据库连接,失败时会抛出异常 7 }; 8 9 class DBConn { //此class用来管理DBConnection对象 10 11 public: 12 ... 13 ~DBConn() { 14 15 db.close(); //确保数据库连接总会被关闭 16 } 17 18 private: 19 DBConnection db; 20 }
客户很可能会写出如下代码:
1 { 2 DBConn dbc( DBConnection::create() ) 3 ... 4 //在区块结束点,DBConn对象被销毁,∴自动为DBConnection对象调用close 5 }
若调用close()成功一切好说;若该调用导致异常,DBConn析构函数会传播该异常,也即允许它离开这个析构函数,这就会造成问题!!!
三个办法可以解决:(前两个方法无吸引力,第三个是较佳策略)
方法一:若close抛出异常就结束程序:
1 DBConn::~DBConn() { 2 3 try { 4 5 db.close(); 6 } 7 catch(...) { //...表示捕获所有的异常 8 只做运转记录,记下对close的调用失败 9 std::abort(); 10 } 11 }
方法二:吞下因调用close而发生的异常
1 DBConn::~DBConn() { 2 3 try { 4 5 db.close(); 6 } 7 catch(...) { 8 制作运转记录,记下对close的调用失败 9 } 10 }
方法三:较佳策略
重新设计DBConn接口,使其客户有机会对可能出现的问题作出反应(即让客户自己参与!):
1 class DBConn { 2 3 public: 4 ... 5 void close() { //供客户使用的新函数 6 7 db.close(); 8 closed = true; 9 } 10 11 ~DBConn() { 12 13 if( !closed ) {//若客户忘了调用close函数,则由destructor来关闭,这是双保险 14 15 try { 16 17 db.close(); 18 } 19 catch(...) { //吞下所有异常 20 21 制作运转记录,记下对close的调用失败 22 } 23 } 24 25 } 26 27 private: 28 DBConnection db; 29 bool closed; 30 };