1.别让异常逃离析构函数的原因

《Effective C++》第三版中条款08建议不要在析构函数中抛出异常,原因是C++异常机制不能同时处理两个或两个以上的异常。多个异常同时存在的情况下,程序若不结束,会导致不明确行为。如下代码:

class Widget{
public:
    ~Widget(){...}    //假设这个可能吐出一个异常
};
void dosomething(){
    vector<Widget> v;
}                    //v在这里被自动销毁

函数dosomething运行结束后,最为栈对象的vector v将被销毁,它同时也有责任销毁其内含的所有Widgets。假设v内含十个Widgets,而在析构第一个元素期间,有个异常被抛出。其他九个widgets还是应该被销毁(否则他们保存的任何资源都会发生泄漏),因此v应该调用它们各个析构函数。但假设在那些调用期间,第二个widget析构函数又抛出异常,这就出现了上面说的情况,多个异常同时存在的情况下,程序若不结束,会导致不明确行为。

2.解决办法

如果析构函数必须执行一个动作,而该动作可能会在失败时抛出异常,该怎么办?举个例子,假设你使用一个class负责数据库连接:

class DBConnection {
public:
   ...
   static DBConnection create(); //返回DBConnection对象;为求简化暂略参数
   void close(); //关闭联机;失败则抛出异常。
};

为确保客户不忘记在DBConnection对象身上调用close(),一个合理的想法是创建一个用来管理DBConection资源的class,并在其析构函数中调用close。这就是著名的以以对象管理资源

class DBConn { //这个class用来管理DBConnection对象
public:
   ...
  DBConn(const DBConnection& db){
       this->db=db;
   }
  ~DBConn() //确保数据库连接总是会被关闭
  {
      db.close();
  }
  
private:
   DBConnection db;
};

调用close成功,一切都美好。但如果该调用导致异常,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 {       //关闭连接(如果客户不调用DBConn::close)
                  db.close();
            }
            catch(...) { //如果关闭动作失败,记录下来并结束程序或吞下异常。
                制作运转记录,记下对close的调用失败;
                ...
           }
        }
    }
private:
    DBConnection db;
    bool closed;
};

本例要说的是,由客户自己调用close并不会对他们带来负担,而是给他们一个处理错误的机会。如果他们不认为这个机会有用(或许他们坚信不会有错误发生),可能忽略它,依赖DBConn析构函数去调用close。

请记住:

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

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


参考文献

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

Effective C++ 条款08:别让异常逃离析构函数的更多相关文章

  1. Effective C++ -----条款08: 别让异常逃离析构函数

    析构函数绝对不要吐出异常.如果一个被析构函数调用的函数可能抛出异常,析构函数应该捕捉任何异常,然后吞下它们(不传播)或结束程序. 如果客户需要对某个操作函数运行期间抛出的异常作出反应,那么class应 ...

  2. Effective C++ 条款八 别让异常逃离析构函数

    class DBConn //这个class用来管理DBConnction对象 { public:   //自己设计一个新的DBConn接口 方法3 void close() { db.close() ...

  3. EC读书笔记系列之4:条款8 别让异常逃离析构函数

    条款8 别让异常逃离析构函数 记住: ★析构函数绝对不要吐出异常.若一个被析构函数调用的函数可能抛出异常,析构函数应该捕捉任何异常,然后吞下它们(不传播)或结束程序. ★若客户需对某个操作函数运行期间 ...

  4. Effective C++_笔记_条款08_别让异常逃离析构函数

    (整理自Effctive C++,转载请注明.整理者:华科小涛@http://www.cnblogs.com/hust-ghtao/) C++并不禁止析构函数吐出异常,但它不鼓励你这样做.考虑如下代码 ...

  5. Effective C++ .08 别让异常逃离析构函数

    异常不怎么用,C++能自己控制析构过程,也就有这个要求了.容器不能完全析构其中的元素真是太危险了

  6. c++之别让异常逃离析构函数

    关于 本文代码演示环境: VS2017. 代码写的够不规范,目的是为了缩短文章篇幅. 本文主要是为了加深印象,写了好多次的代码,还是忘记了这茬.... 之前上传到github的代码会慢慢改过来. 本文 ...

  7. 《Effective C++》——条款08:别让异常逃离析构函数

    考虑如下代码: class Widget{ public: ... ~Widget(){...}//假设这个可能吐出一个异常 }; void doSomething() { std::vector&l ...

  8. Effective C++ -----条款29:为“异常安全”而努力是值得的

    异常安全函数(Exception-safe functions)即使发生异常也不会泄露资源或允许任何数据结构败坏.这样的函数区分为三种可能的保证:基本型.强烈型.不抛异常型. “强烈保证”往往能够以c ...

  9. [Effective C++ --008]别让异常逃离析构函数

    这章非常容易理解:因为C++并不禁止析构函数吐出异常,只是不鼓励这样做而已. 一.原因 假设我们有10个装着鸡蛋的容器,而且现在我们还想着把它在析构函数打烂. class Egg { public : ...

随机推荐

  1. 如何在多机架(rack)配置环境中部署cassandra节点

    cassandra节点上数据的分布和存储是由系统自动完成的.除了我们要设计好partition key之外,在多机架(rack)配置环境中部署cassandra节点,也需要考虑cassandra分布数 ...

  2. 通过spark-submit提交hadoop配置的方法

    通过spark提交的spark开头的配置在程序启动后会添加到SparkConf中,但是hadoop相关的配置非spark开头会被过滤掉,但是只要在这些配置的key前面添加spark.hadoop.前缀 ...

  3. 单一docker主机网络

    一. 容器网络模型: Docker定义了一个非常简单的网络模型,叫做container network model(CNM).如下图所示:

  4. 基于C#的机器学习--目录

    转载请注明出处:https://www.cnblogs.com/wangzhenyao1994/p/10223666.html 文章发表的另一个地址:https://blog.csdn.net/wyz ...

  5. wifi,Android渗透之arp欺骗

    查看自己wifi ip段 查看有哪些用户连接了此wifi,下图标记处为我的测试机(华为) 攻击开始,如果开启了arp防火墙,就会有提示 开启图片捕获

  6. Structs2笔记③--局部类型转换案例

    Structs2的类型转换-局部类型转换 Ognl强大的表达式语言,在导入项目的时候我们导入了ognl.jar包,内有TypeConverter类,struct主要依赖于他进行类型转换. 例子   i ...

  7. 【CSAPP笔记】9. 汇编语言——缓冲区溢出

    x86-64 Linux 内存结构 先来看看一个程序在内存中是如何组织的.Linux 为每个进程维持了一段单独的虚拟地址空间.(进程是计算机科学中很深刻.很成功的一个概念.当我们在运行一个程序时,会得 ...

  8. python 安装pymssql

    error: command 'gcc' failed with exit status 1 ---------------------------------------- Command &quo ...

  9. Caffe使用step by step:使用自己数据对已经训练好的模型进行finetuning

    在经过前面Caffe框架的搭建以及caffe基本框架的了解之后,接下来就要回到正题:使用caffe来进行模型的训练. 但如果对caffe并不是特别熟悉的话,从头开始训练一个模型会花费很多时间和精力,需 ...

  10. macOS & SVN

    macOS & SVN mac 下已经自带了svn环境; 使用 svn –version 查看版本号 安装方法: 已安装 XCode,只需要在 code > Preferences &g ...