Effective C++条款29：实现之（为“异常安全”而努力是值得的）

原创

董哥的黑板报 2022-04-02 16:47:19 博主文章分类：Effective C++ ©著作权

文章标签 EffectiveC++ 互斥抛出异常异常安全 文章分类 代码人生

©著作权归作者所有：来自51CTO博客作者董哥的黑板报的原创作品，请联系作者获取转载授权，否则将追究法律责任

一、可能抛出异常的演示案例

下面是一个class，用来表现夹带背景图片的GUI菜单单，其中有个互斥器作为并发控制：

void lock(Mutex* pm);   //锁定pm所指的互斥器
void unlock(Mutex* pm); //将互斥器解锁

class PrettyMenu {
public:
    void changeBackground(std::istream& imgSrc) {
        lock(&mutex);   //取得互斥器
        delete bgImage; //删除旧图片
        ++imageChanges; //修改图像更改次数
        bgImage = new Image(imgSrc); //安装新的背景图片
        unlock(&mutex); //释放互斥器
    }
private:
    Mutex mutex;     //互斥器
    Image* bgImage;  //目前使用的背景图片
    int imageChanges;//图片被修改的次数
};

上面的changeBackground()成员函数不是“异常安全的”。因为异常安全的函数应该有以下两种特性：

①不泄露任何资源：上述的代码如果new Image()操作导致异常，那么就永远不会调用unlock，那么互斥器将永远被锁住。因此该成员函数没有保证这一点
②不允许数据破坏：如果new Image()操作导致异常，那么bgImage已经被删除了，而且imageChanges数量也被累加了，所以资源被改变了。但是该函数没有保证这一点

二、解决资源泄露的问题

这个问题很容易解决，在条款13中讨论了如何以对象管理资源，条款14也介绍了自己设计一个名为Lock的类来管理互斥器，定义如下：

//初始化对象时锁住互斥器，对象释放时自动解除互斥器
class Lock
{
public:
    //获得资源
    explicit Lock(Mutex* pm) :mutexPtr(pm) {
        lock(mutexPtr);
    }
 
    //释放资源
    ~Lock() { unlock(mutexPtr); }
private:
    Mutex *mutexPtr;
};

//重写修改PrettyMenu的成员函数
void PrettyMenu::changeBackground(std::istream& imgSrc) {
    Lock ml(&mutex);//将互斥器封装在类中进行管理
    delete bgImage; //删除旧图片
    ++imageChanges; //修改图像更改次数
    bgImage = new Image(imgSrc); //安装新的背景图片
}

上面我们将互斥器对象封装在一个类中，初始化时锁住互斥器，当对象声明周期结束之后不需要我们手动释放互斥器，析构函数会自动帮我们释放互斥器，因此这种方法可以很好的解决资源泄漏的问题

三、解决数据破坏的问题

上面介绍了资源泄漏的一般解决办法，现在来关注一下数据破坏的问题。在此之前我们先定义一些术语：

①基本承诺：如果异常被抛出，程序内的任何事物都应该保持在有效状态
②强烈保证：如果程序抛出异常，程序状态不应该保证。调用这样的函数应该保证：如果函数成功就是完全成功；如果函数执行失败，程序会恢复到“调用函数之前”的状态
③不抛掷保证：承诺绝不抛出异常，因为它们总是能够完成它们原先承诺的功能

C++提供两种异常说明：

throw，参阅：
noexcept，参阅：

虽然可以使用上面两种异常说明来显式说明函数不会抛出异常，但是如果函数抛出了异常还是允许的

异常安全的代码必须提供上述三种保证之一，如果不是这样，那么代码就不是异常安全的
对于changeBackground()函数而言，为了保证数据不被破坏，可以更改为下面的代码：

使用智能指针来管理Image对象
重新排序changeBackground()函数内的语句顺序，使得更换图像之后才累加imageChanges
在changeBackground()函数内部不需要手动删除delete旧图像了，因为已经由智能指针自动管理删除了（在reset的内部被调用）

class PrettyMenu {
//...
private:
    std::tr1::shared_ptr<Image> bgImage;
};

//重写修改PrettyMenu的成员函数
void PrettyMenu::changeBackground(std::istream& imgSrc) {
    Lock ml(&mutex);
    bgImage.reset(new Image(imgSrc));
    ++imageChanges;
}

四、copy-and-swap策略

“三”中虽然解决了数据破坏的问题，但是还有一个问题没有解决，那就是在在changeBackground()函数中，Image的构造函数可能会抛出异常
copy and swap策略的原则是：为你打算修改的对象（原件）做一份副本，然后在副本身上做修改：

如果在副本的身上修改抛出了异常，那么原对象未改变状态
如果在副本的身上修改未抛出异常，那么就将修改过的副本与原对象进行置换（swap）

pimpl idiom手法：

将原对象封装到一个类中（或结构）中
这种手法称为pimpl idiom，在条款31会讲解

对于上面的PrettyMenu来说，典型的写法如下：

演示案例

对于上面的PrettyMenu来说，典型的写法如下：

//将bgImage和imageChanges从PrettyMenu独立出来，封装到一个结构中
struct PMImpl {
    std::tr1::shared_ptr<Image> bgImage;
    int imageChanges
};

class PrettyMenu {
    //...
private:
    std::tr1::shared_ptr<PMImpl> pImpl; //创建一个该结构
};

现在我们重新修改changeBackground()函数：

void PrettyMenu::changeBackground(std::istream& imgSrc) {
    using std::swap; //见条款25

    Lock ml(&mutex);
    
    //以pImpl为原件，创建一个副本，然后在副本上做修改
    std::tr1::shared_ptr<PMImpl> pNew(new PMImpl(*pImpl));
    pNew->bgImage.reset(new Image(imgSrc));
    pNew->imageChanges++;

    //如果上面副本的修改没有抛出异常，那么交换副本与原件
    swap(pImpl, pNew);
}