《Effective C++ 》学习笔记——条款08

***************************************转载请注明出处:http://blog.csdn.net/lttree********************************************

二、Constructors,Destructors and Assignment Operators

Rule 08:Prevent exceptions from leaving destructors

规则08:别让异常逃离析构函数

1.再来谈一个C++讨厌的东西

C++并不禁止析构函数吐出异常,但它不鼓励你这样做。

首先,看下面这个例子:

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

当vector v 被销毁,它就会将所有Widget销毁。加入v有10个Widget,在析构第一个Widget时,有一个异常被抛出,Ok,还有九个要被销毁,在销毁第二个时,又有一个异常抛出。额。。。这下对于C++来说就有些多了。在两个异常同时存在的情况下,程序若不是结束执行就是导致不明确的行为。So,C++不喜欢析构函数吐出异常。

2.即使知道C++讨厌,但我们无法避免要面对它

如果析构函数必须执行某个动作,但这个动作可能导致异常,怎么办呢?

依旧用书上的例子,用一个类来负责数据库连接:

class DBConnection  {
public:
    ...
    static DBConnection create();

    void close();
};

但是为了确保客户不忘记在 DBConnection 对象上调用close(),一个合理的想法是创建一个用来管理DBConnection资源的class并在其析构函数中调用close,如同下面这种:

class DBConn  {
public:
    ...
    ~DBConn()
    {
        db.close();
    }
private:
    DBConnection db;
};

但是这样就会允许用户写出这样的代码:

{
    DBConn dbc( DBConnection::create() );

    ...
}<span style="white-space:pre">				</span>// 在块结束时DBConn对象被销毁,因为自动为DBConnection对象调用close

这就是个很大的问题了,只要调用成功,那就一切美好,如果调用导致异常,则会导致异常的传播,这就相当糟糕。

对于这个情况有两个方案来搞定:

<1>plan01:

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

DBConn::~DBConn( )
{
    try{ db.close(); }
    catch( ... )  {<span style="font-family: Arial, Helvetica, sans-serif;">    </span>
<pre name="code" class="cpp">      制作运转记录,记下对close的调用失败;

std::abort(); }}


对于出现异常,就强迫结束程序。毕竟它可以阻止异常从析构函数传播出去。

<2>plan02:

吞下因调用close而发生的异常

DBConn::~DBConn( )
{
    try { db.close(); }
    catch ( ... )  {
        制作运转记录,记下对close的调用失败;
    }
}

一般的来说,吞下异常是个坏主意,因为它压制了“某些动作失败”的重要信息!然而有时吞下异常也比 “ 草率的结束程序 ” 或者 “ 不明确的行为带来的风险” 好。

3.更好的方法?

上面两种方法都是因为 无法对 导致close抛出异常 的情况作出反应。

所以,更好的办法,就是 重新设计 DBConn 的接口,比如:

class DBConn  {
public:
    ...
    void close()<span style="white-space:pre">		</span>// 供用户使用的新函数
    {
        db.close();
        closed = true;
    }
    ~DBConn()
    {
        if( !closed )  {
            try  {<span style="white-space:pre">		</span>// 如果用户没有关闭连接,则执行关闭连接
                db.close();
            }
            catch  ( ... )  {<span style="white-space:pre">	</span>// 如果关闭动作失败
                制作运转记录,记下对close的调用失败;
                ....
            }
        }
    }
private:
    DBConnection db;
    bool closed;
};

这个方案很易于理解,设置一个bool类型变量检测,如果用户直到结束,也没有将连接关闭,则替用户关闭连接,否则,如果用户关闭了连接,我们无需在做任何事情。在关闭连接时,若发生异常抛出,那就只能回到 吞下异常 这条老路了,这个是怎么也避免不了了。

这个方案的优点,把调用close责任给到用户手上,但是还设置了一个双保险,让程序更加安全。

4.请记住:

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

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

***************************************转载请注明出处:http://blog.csdn.net/lttree********************************************

时间: 2024-08-30 02:11:46

《Effective C++ 》学习笔记——条款08的相关文章

effective C++ 读书笔记 条款08

条款08  别让异常逃离析构函数: 假设在析构函数其中发生了异常,程序可能会过早结束或者导致不明白行为(异常从析构函数传播出去) 看代码: #include <iostream> using namespace std; class DBConnection { public: void close() { int i = 3; int j = 0; int k = i/j; printf("%d\n",k); } }; class DBConn { public: DBC

effective c++学习笔记条款23-25

条款23:宁可用非成员,非友元函数来替代成员函数 1.非成员函数提供了更好的封装性,这个函数内不能访问类的私有成员,封装的越严密我们对类的数据就可以弹性越大的操纵,因为可见这些数据的客户越少,反之数据影响的客户也就越少. 2.c++比较自然的做法-(关系到标准库numplace的组织结构),可以把不同便捷函数放到不同Namespace去,让客户来决定要用的非成员函数功能,这是类不能提供的. 条款24:若所有参数皆需类型转换,请为此采用非成员函数. 1.如果你需要为某个函数的所有参数(包括被thi

effective c++学习笔记条款11-13

条款11: 1.令赋值运算符返回一个&,因为STL,string都是这样做的,除非你有足够好的理由不这样做. 2.处理自我赋值的方法----(1).在没有成功获取对象数据时不要删除自己的数据,避免发生异常后原对象指针是一个悬浮指针 (2).判断自我赋值的检查操作会耗费不少时间,可以用swap交换数据技术来优化---(1)形参为赋值而来,(2)形参为静态引用,多加一个函数内拷贝操作.

effective c++学习笔记条款8-10

条款7:为多态基类声明虚析构函数 1.一个基类指针接受一个派生类对象的地址时,对该指针delete,仅仅释放基类部分 2.给所有类都带上虚析构函数是个馊主意,会带有vptr指向一个函数指针数组,扩大不必要的对象大小,除非补偿vptr,否则没有移植性. 3.string类和STL不含有虚析构函数,然而一些用户 却将他们作为基类,运用   delete指向派生类的基类指针,导致错误[c++11添加了禁止派生性质],他们不适合当基类. 4,手头上没有合适的纯虚函数,但你确实需要一个抽象类,把析构函数声

effective c++学习笔记条款20-22

条款20:用引用传递代替值传递 1.尽量以引用传递来代替传值传递,前者比较高效,并且可以避免切割问题 2.以上规则不适用于内置类型,以及STL的迭代器,和函数对象 条款21:必须返回对象时,别妄想返回对象的引用 1.绝对不要返回指针和引用指向一个局部对象或者静态局部对象而有可能需要多个这样的对象,条款4已经为在单线程环境合理返回&指向一个局部静态提供了一份设计实例.(保护初始化顺序) 条款22:将成员变量声明为private 1.切记将成员变量声明为private.这可赋予客户访问数据的一致性,

effective c++学习笔记条款4-7

条款4:确定对象被使用前已经初始化 一. 变量在不同情况下可能会初始化,也可能不会初始化. 注意初始化和赋值的区别. 1.在类中内置类型不会发生隐式初始化,自定义有默认构造函数的能被默认初始化 所以在构造类时务必初始化内置类型,最好给自定义的对象显示初始化避免在函数体中赋值浪费资源. 2.内置类型在函数体内不会初始化,在函数体外自动初始化为0. 二. 1.const和引用类型必须初始化,不可能赋值 三 1.当类实在是有较多构造函数,并且总是要对一些成员数据重复初始化,可以考虑将那些“赋值和初始化

effective c++学习笔记条款17-19

条款17:以独立语句将New对象放置入智能指针. 1.以独立语句将newed对象放置入智能指针内,如果不这样做,一旦异常被抛出,有可能导致难以察觉的资源泄露. void name(shared_ptr<管理对象类型>(new 管理对象类型),其它函数)),New被分配内存不一定马上放入管理对象,因为有其它函数干扰,这不是独立语句. 条款18:让接口容易被正确使用,不易被误用. 1.好的接口很容易被正确使用,不容易被误用.你应该在你的所有接口中努力达成这些性质. 2.“促进正确使用”的办法包括接

effective c++学习笔记条款35-37

#include<iostream> using namespace std; class A { public: void asd() { pri(); } private: /*virtual*/ void pri() { cout << "基类函数" << endl; } }; class B :public A { private: void pri() /*override*/ { cout << "派生类函数&quo

effective c++学习笔记条款29-31

条款29:为异常安全而努力是值得的[回顾] 1.异常安全函数即使发生异常也不会泄露资源或允许任何数据结构败坏,这样的函数分为3种可能的保证:基本型,强烈型,不抛异常型 2.“强烈保证”往往能通过copying and swap 来实现出来,但并非所有函数都可实现或者具备现实意义. 3.函数提供的“异常安全保证”通常最高只等于其所调用的各个函数的“异常安全中”的最弱者.