条款29：为“异常安全”而努力是值得的

1、抛出异常的案例

假设我们有一个表示GUI菜单的类，这个GUI菜单有背景图片。这个类将被使用在多线程环境中，所以需要mutex进行并发控制。

class PrettyMenu {
public:
	...
    void changeBackground(std::istream& imgSrc) // 改变背景图像
	...
private:
    Mutex mutex;     //互斥器
    Image* bgImage;  //目前使用的背景图片
    int imageChanges;//图片被修改的次数
};

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

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

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

2、解决资源泄露的问题

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

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

使用像Lock一样的资源管理类的一个极大的好处是它通常使函数更短。比如为什么不再需要对unlock的调用了？作为一个通用的规则，代码越少越好，因为对代码做改动时，出错和理解错误的可能性变低了。

3、异常安全的三种保证

接下来让我们看一看数据结构被损坏的问题。这里我们要做出选择，但是在我们可以进行选择之前，必须对定义这些选择的术语做一下比较。

异常安全的函数提供了如下三种保证的一种：

① 基本承诺：如果异常被抛出，程序内的任何事物都应该保持在有效状态。

没有对象或者数据被损坏，并且所有对象或者数据保持一个内部一致的状态（例如所有类的约束条件继续被满足）。然而，程序的正确状态可能不能够被预测出来。例如，我们可以实现changeBackground，一旦异常被抛出，PrettyMenu对象可以继续拥有旧的背景图片，但是客户不能够预测拥有的是哪一个。（为了能够找出这个图片，大概需要调用一些成员函数，来告诉它们当前的背景图片是哪一个）

② 强烈保证：如果程序抛出异常，程序状态不应该保证。调用这样的函数应该保证：如果函数成功就是完全成功；如果函数执行失败，程序会恢复到“调用函数之前”的状态。

使用提供强保证的函数比只提供基本保证的函数要更加容易，因为调用提供强保证的函数之后，只可能有两种程序状态：函数被正确执行后的状态，或者函数被调用之前的状态。而如果在调用只提供基本保证的函数的时候抛出异常，程序可以进入任何有效状态。

不抛掷（nothrow）保证：承诺绝不抛出异常，因为它们总是能够完成它们原先承诺的功能。

所有在内置类型上进行的操作都是无异常的。这是异常安全代码的一个关键的构建基础。

认为带有空异常明细（empty exception specification）的函数是无异常的，这可能看上去是合理的，但事实上不是这样。举个例子，如： int doSomething() throw();//空白的异常明细
这并不是说doSomething永远不会抛出异常。它的意思是如果soSomething抛出异常，就会是一个严重的错误，并且会调用意料不到的函数。事实上，doSomething没有提供任何异常安全保证。这个函数的声明（如果有异常明细，也包含异常明细）并没有告诉你这个函数是否是正确的，可移植的或者效率高的，也没有为你提供任何异常安全保证。所有这些特性都由函数的实现来决定，而不是声明。

NOTE：异常安全的代码必须提供上面三种保证的一种。如果没有提供，它就不是异常安全的。

4、两种解决异常安全的方法

4.1 使用智能指针

对于changeBackground来说，提供强烈保证不是多难的事。

首先，我们将PrettyMenu的bgImage数据成员的类型从内建的Image*指针替换为一种资源管理智能指针(见条款13)。说真的，对于防止资源泄露来说这绝对是一个好方法。它帮我们提供强异常安全保证的事实只是简单对条款13中的论述(使用对象管理资源是好的设计的基础)做了进一步的加强。在下面的代码中，我将会展示tr1::shared_ptr的使用，因为当进行拷贝时使用tr1::shared_ptr比使用auto_ptr更加直观，更受欢迎。

第二，我们对changeBackground中的语句进行重新排序，达到只有image被修改的时候才会增加imageChnages的目的。作为通用准则，一个对象的状态没有被修改就表明一些事情没有发生。

class PrettyMenu {
...
private:
    std::tr1::shared_ptr<Image> bgImage;
};
//修改后的PrettyMenu的成员函数
void PrettyMenu::changeBackground(std::istream& imgSrc) {
	Lock ml(&mutex);
	bgImage.reset(new Image(imgSrc));//以"new Image"的执行结果
	++imageChanges;//设定bgImage内部指针
}

注意这里不再需要手动delete旧图像，因为这由智能指针在内部处理。并且，销毁操作只有在新image成功创建的时候才会发生。更精确的说，只有在参数（new Image(imgSrc)的结果）被成功创建的时候tr1::shared_ptr::reset函数才会被调用。delete只在reset函数内部被使用，所以如果reset不被调用，delete永远不会被执行。注意资源管理对象的使用再次削减了changeBackground的长度。

正如我所说的，上面的两个修改足以为changeBackground提供强异常安全保证。还有美中不足的就是关于参数imgSrc。如果Image的构造函数抛出异常，输入流的读标记可能会被移动，这个移动致使状态发生变化并且对程序接下来的运行是可见的。如果changeBackground不处理这个问题，它只能提供基本异常安全保证。

4.2 拷贝和交换

“3”中只解决了基本保证，但在changeBackground()函数中，Image的构造函数可能会抛出异常，也就是无法提供强烈保证。有个一般化的设计策略很典型地会导致强烈保证，很值得熟悉它。这个策略就是copy and swap。

copy and swap策略的原则是：为你打算修改的对象（原件）做一份副本，然后在副本身上做修改：

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

实际上通常是将所有“隶属对象的数据”从原对象放进另一个对象内，然后赋予原对象一个指针，指向那个所谓的实现对象（即副本）。这种收发被称为“pimpl idiom”，在条款31中会进行描述。对于上面的PrettyMenu来说，典型的写法如下：

struct PMImpl {//将bgImage和imageChanges从PrettyMenu独立出来，封装成一个结构体
    std::tr1::shared_ptr<Image> bgImage;
    int imageChanges
};
class PrettyMenu {
    //...
private:
    std::tr1::shared_ptr<PMImpl> pImpl; //创建一个该结构
};
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);
}

在这个例子中，我选择将PMImpl定义为一个结构体而不是类，因为PrettyMenu的封装性通过pImpl的私有性（private）来保证。把PMImpl定义成类会至少和结构体一样好，虽然有一些不方便。如果需要，PMImpl可以被放在PrettyMenu中，但是打包问题（packaging）是我们所牵挂的。