Effective c++学习笔记——条款08:别让异常逃离析构函数

 
Prevent exceptions from leaving destructors   
         本条款主要讲述当我们写代码的时候,如果出现了异常,让我们如何对异常处理,如何更加安全的处理异常。让我们的代码看起来更加完美。
      1、问题来源
        案例1
        由于C++并不禁止析构函数吐出异常,但它并不鼓励你这么做,所以,当我们不小心写出了问题代码的时候。考虑下面的代码:

c++并不禁止析构函数吐出异常,但它并不鼓励你这么做。考虑下面的代码:
class Widget
{
public:
~Widget(){...} //假设这个可能吐出一个异常
};
void dosomething()
{
vector<Widget> v;
} //v在这里被自动销毁

当vector被销毁,它有责任销毁其内含的所有Widgets。假设v内含十个Widgets,而在析构第一个元素期间,有个异常被抛出。其他九个widgets还是应该被销毁,因此v应该调用它们各个析构函数。但假设在那些调用期间,第二个widget析构函数又抛出异常。现在有两个同时作用的异常,这对c++而言太多了。
在两个异常同时存在的情况下,程序若不是结束执行就是导致不明确行为。本例中会导致不明确的行为。使用标准程序库的任何其他容器或TR1的任何容器或甚至array,也会出现相同情况。容器或array并非遇上麻烦的必要条件,只要析构函数吐出异常,即使并非使用容器或arrays,程序也可能过早结束或出现不明确行为。使得,c++不喜欢析构函数吐出异常!

    案例2

        这很容易理解,但如果你的析构函数必须执行一个动作,而该动作可能会在失败时抛出异常,该怎么办?举个例子,假设你使用一个class负责数据库连接:
class DBConnection {
   public:
   ...
   static DBConnection create(); //这个函数返回DBConnection对象;为求简化暂略参数。
   void close(); //关闭联机;失败则抛出异常。
   };

2、解决方案

        为确保客户不忘记在DBConnection对象身上调用close(),一个合理的想法是创建一个用来管理DBConection资源的class,并在其析构函数中调用close。这一类用于资源管理的classes在第3章有详细探讨,这儿只要考虑它们的析构函数长相就够了:

class DBConn { //这个class用来管理DBConnection对象
   public:
   ...
  ~DBConn() //确保数据库连接总是会被关闭
   {
   db.close();
   }
   private:
   DBConnection db;
   };
这便允许客户写出这样的代码:

{ //开启一个区块(Block)。
  DBConn dbc(DBConnection::create()); //建立DBConnection对象并交给DBConn对象以便管理。通过DBConn的接口使用DBConnection对象。
  ... //在区块结束点,DBConn对象被销毁,因而自动为DBConnection对象调用close。
   }

        只要调用close成功,一切都美好。但如果该调用导致异常,DBConn析构函数会传播该异常,也就是允许它离开这个析构函数。那会造成问题,因为那就是抛出了难以驾驭的麻烦。
  两个办法可以避免这个问题。DBConn的析构函数可以:
   方案1、 如果close抛出异常就结束程序,通常调用abort完成:
DBConn::~DBconn()
{
try { db.close(); }
catch(...)
{
abort();
}
}

如果程序遭遇一个“于析构期间发生的错误”后无法继续执行,“强制结束程序”是个合理选项,毕竟它可以阻止异常从析构函数传播出去(那会导致不明确的行为)。也就是说调用abort可以抢先制“不明确行为”于死地。

方案2、吞下因调用close而发生的异常:
DBConn::~DBConn
{
try{ db.close(); }
catch(...)
{
//制作运转记录,记下对close的调用失败!
}
}

    3、进一步方案
    一般而言,将异常吞掉是个坏主意,因为它压制了“某些动作失败”的重要信息!然而有时候吞下异常也比负担“草率结束程序”或“不明确行为带来的风险”好。为了让这成为一个可行方案,程序必须能够继续可靠的执行,即使在遭遇并忽略一个错误之后。

    这些办法都不怎么样,一个较佳的策略是重新设计DBConn接口,使其客户有机会对可能出现的问题作出反应。例如DBConn自己可以提供一个close函数,因而赋予客户一个机会可以处理“因该操作而发生的异常”。
把调用close的责任从DBConn析构函数手上移到DBConn客户手中,你也许会认为它违反了“让接口容易被正确使用”的忠告。实际上这污名并不成立。如果某个操作可能在失败的时候抛出异常,而又存在某种需要必须处理该异常,那么这个异常必须来自析构函数以外的某个函数。因为析构函数吐出异常就是危险,总会带来“过早结束程序”或“发生不明确行为”的风险。

class DBConn {
public:
...
void close() //供客户使用的新函数
{
db.close();
closed = true;
}
~DBConn()
{
if(!closed) {
try { //关闭连接(如果客户不那么做的话)
db.close();
}
catch(...) { //如果关闭动作失败,记录下来并结束程序或吞下异常。
制作运转记录,记下对close的调用失败;
...
}
}
}
private:
DBConnection db;
bool closed;
};
本例要说的是,由客户自己调用close并不会对他们带来负担,二十给他们一个处理错误的机会,否则他们没机会相应。如果他们不认为这个机会有用(或许他们坚信不会有错误发生),可能忽略它,依赖DBConn析构函数去调用close。如果真有错误发生——如果close的确抛出异常——而且DBConn吞下该异常或结束程序,客户没有立场抱怨,毕竟他们曾有机会第一手处理问题,而他们选择了放弃。

请记住:


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


2.如果客户需要对某个操作函数运行期间抛出的异常作出反应,那么class应该提供一个普通函数(而非在析构函数中)执行该操作。


评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值