Effective C++ 读书笔记 Item29 追求异常安全的代码

朱雀 2020-07-05 02:30 949阅读 0赞

考虑下面例子，有一个菜单类， changeBg 函数可以改变它的背景，切换背景计数，同时提供线程安全：

class Menu{
    
        Mutex mutex; //提供多线程互斥访问
        Image *bg; //背景图片
        int changeCount; //切换背景计数
    
    public :
        void changeBg(istream& sr);
    };
        void Menu::changeBg(istream& src){
        lock(&mutex);
        delete bg;
        ++changeCount;
        bg = new Image(src);
        unlock(&mutex);
    }

1）异常安全的 2 个条件  
异常安全有 2 个条件：  
1. 不泄露任何资源：即发生异常时，异常发生之前获得的资源都应该释放，不会因为异常而泄露。在  
上面的例子中，如果 new Image 发生异常，那么 unlock 就不会调用，因此锁资源会泄露  
2. 不允许数据败坏：上面的例子也不符合，如果 new Image 异常， 背景图片会被删除，计数也会改变。  
但是新背景并未设置成功  
对于资源泄露， 条款 13 讨论过以对象管理资源。锁资源也可以为 shared\_ptr 指定“删除器”，当引用为 0  
时，即异常发生，管理所资源的对象被销毁后，删除器会调用 unlock  
对于数据败坏：见下文  
2）异常安全函数的 3 个保证  
1. 基本承诺：抛出异常后，对象仍然处于合法（valid）的状态。但不确定处于哪个状态（对于前面的  
例子，如果发生异常， PrettyMenu 可以继续拥有原背景图像，或是令它拥有某个“缺省”的背景图像，  
但客户无法确定）  
2. 强烈保证：如果抛出了异常， 状态并不会发生发生任何改变。就像没调用这个函数一样  
3. 不抛掷保证：这是最强的保证，函数总是能完成它所承诺的事情（作用于内置类型身上的所有操作  
都提供 nothrow 保证。这是异常安全代码中一个必不可少的关键基础）  
对于前面的 PrettyMenu 对象，可以通过使用智能指针，以及重排 changeBg 的语句顺序来满足“强烈保  
证”：

class Menu{
    shared_ptr<Image> bg;
    ...
    };
    void Menu::changeBg(istream& src){
    Lock m1(&mutex); //Lock 以对象管理资源
    bg.reset(new Image(src));
    ++changeCount;
    }

注意，上述实现只能为 PrettyMenu 对象提供“强烈保证”，不能提供完美（即全局状态）的“强烈保证”。  
比如 Image 构造函数中移动了 istream& src 的读指针然后再抛出异常，那么系统还是处于一个被改变的  
状态。 这是一种对整个系统的副作用，类似的副作用还包括数据库操作，因为没有通用的办法可以撤销  
数据库操作。 不过这一点可以忽略，我们暂且认为它提供了完美的强烈保证  
**copy and swap 策略**

--------------------

“copy and swap”设计策略通常能够为对象提供异常安全的“强烈保证”。当我们要改变一个对象时，先把  
它复制一份，然后去修改它的副本，改好了再与原对象交换。 关于 swap 的详细讨论可以参见条款 25。  
这种策略用在前面的例子中会像这样：

class Menu{
    ...
        private:
        Mutex mutex;
        std::shared_ptr<MenuImpl> pImpl;
    };
    Menu::changeBg(std::istream& src){
        using std::swap; // 见 Item 25
        Lock m1(&mutex); // 获得 mutex 的副本数据
        std::shared_ptr<MenuImpl> copy(new MenuImpl(*pImpl));
        copy->bg.reset(new Image(src)); //修改副本数据
        ++copy->changeCount;
        swap(pImpl, copy); //置换数据，释放 mutex
    }

copy and swap 策略能够为对象提供异常安全的“强烈保证”。但是一般而言，它并不保证整个函数有“强烈  
保证”。也就是说，如果某个函数使用 copy and swap 策略为某个对象提供了异常安全的“强烈保证”。但  
是这个函数可能调用其它函数，而这些函数可能改变一些全局状态（如数据库状态），那么”整个函数“就  
不是”强烈保证“  
函数提供的”异常安全保证“通常最高只等于其所调用的各个函数的”异常安全保证“中的最弱者  
除此之外， copy and swap 必须为每一个即将被改动的对象作出一个副本，从而可能造成时间和空间上的  
问题  
3）最终目标是什么  
当”强烈保证“不切实际时（比如前面提到的全局状态改变难以保证，或者效率问题），就必须提供”基本  
保证“。现实中你或许会发现，可以为某些函数提供强烈保证，但效率和复杂度带来的成本会使它对许多  
人而言摇摇欲坠。只要你曾经付出适当的心力试图提供强烈保证，万一实际不可行，使你退而求其次地  
只提供基本保证，任何人都不该因此责难你。对许多函数而言， ”异常安全性的基本保证“是一个绝对同情  
达理的选择  
总的来说就是，应该为自己的函数努力实现尽可能高级别的异常安全，但是由于种种原因并不是说一定  
需要实现最高级别的异常安全，而是应该以此为目标而努力。