条款29：为“异常安全”而努力是值得的（来自百度空间）
有个class用来表现夹带背景图案的GUI菜单单，这个class用于多线程环境：
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);
}
从异常安全性的角度看，这个函数很糟。“异常安全”有两个条件：当异常被抛出时，带有异常安全性的函数会：
不泄露任何资源。上述代码没有做到这一点，因为一旦“new Image（imgSrc）”导致异常，对unlock就不会执行，于是互斥器就永远被把持住了。
不允许数据破坏。如果“new Image（imgSrc）”抛出异常，bgImage就指向一个已被删除的对象，imageChanges也已被累加，而其实并没有新的图像被 成功安装起来。
解决资源泄漏的问题很容易，
void PrettyMenu::changeBackground(std::istream& imgSrc)
{
Lock ml(&mutex);//来自条款14；
delete bgImage;
++imageChanges;
bgImage = new Image(imgSrc);
}
关于“资源管理类”如Lock，一个最棒的事情是，它们通常使函数更短。较少的代码就是较好的代码，因为出错的机会比较少。
异常安全函数（Exception-safe function）提供以下三个保证之一：
基本承诺：如果异常被抛出，程序内的任何事物仍然保持在有效状态下。没有任何对象或数据结构会因此而败坏，所有对象都处于一种内部前后一致的状态（例如所有的class约束条件都继续获得满足）。然而程序的现实状态恐怕不可预料。如上例changeBackground使得一旦有异常被抛出时，PrettyMenu对象可以继续拥有原背景图像，或是令它拥有某个缺省背景图像，但客户无法预期哪一种情况。如果想知道，它们恐怕必须调用某个成员函数以得知当时的背景图像是什么。
强烈保证：如果异常被抛出， 程序状态不改变。如果函数成功，就是完全成功，否则，程序会回复到“调用函数之前”的状态。
不抛掷（nothrow）保证：承诺绝不抛出异常，因为它们总是能够完成它们原先承诺的功能。作用于内置类型（如ints，指针等等）上的所有操作都提供nothrow保证。带着“空白异常明细”的函数必为nothrow函数，其实不尽然
int doSomething() throw(); //”空白异常明细”
这并不是说doSomething绝不会抛出异常，而是说如果抛出异常，将是严重错误，会有你意想不到的函数被调用。实际上doSomething也许完全没有提供任何异常保证。函数的声明式（包括异常明细）并不能告诉你是否它是正确的、可移植的或高效的，也不能告诉你它是否提供任何异常安全性保证。
异常安全码（Exception-safe code）必须提供上述三种保证之一。否则，它就不具备异常安全性。
一般而言，应该会想提供可实施的最强烈保证。nothrow函数很棒，但我们很难再c part of c++领域中完全没有调用任何一个可能抛出异常的函数。所以大部分函数而言，抉择往往落在基本保证和强烈保证之间
对changeBackground而言，首先，从一个类型为Image*的内置指针改为一个“用于资源管理”的智能指针，第二，重新排列changeBackground内的语句次序，使得在更换图像之后再累加imageChanges。
class PrettyMenu{
...
std::tr1::shared_ptr<Image> bgImage;
...
};
void PrettyMenu::changeBackground(std::istream& imgSrc)
{
Lock ml(&mutex);
bgImage.reset(new Image(imgSrc));
++imageChanges;
}
不再需要手动delete旧图像，只有在reset在其参数（也就是“new Image（imgSrc）”的执行结果）被成功生成之后才会被调用。美中不足的是参数imgSrc。如果Image构造函数抛出异常，有可能输入流的读取记号（read marker）已被移走，而这样的搬移对程序其余部分是一种可见的状态改变。所以在解决这个之前只提供基本点异常安全保证。
有一个一般化的策略很典型会导致强烈保证，被称为“copy and swap”：为打算修改的对象做一个副本，
在那个副本上做一切必要修改。若有任何修改动作抛出异常，源对象仍然保持未改变状态。待所有改变都成功后，再将修改过的副本和原对象在一个不抛出异常的swap中置换
实现上通常是将所有“隶属对象的数据”从原对象放进另一个对象内，然后赋予源对象一个指针，指向那个所谓的实现对象（implementation object，即副本）。对PrettyMenu而言，典型的写法如下：
struct PMImpl{
std::tr1::shared_ptr<Image> bgImage;
int imageChanges;
};
class PrettyMenu{
...
private:
Mutex mutex;
std::tr1::shared_ptr<PMImpl> pImpl;
};
void PrettyMenu::changeBackground(std::istream& imgSrc)
{
using std::swap;
Lock ml(&mutex);
std::tr1::shared_ptr<PMImpl> pNew(new PMImpl(*pImpl));
pNew->bgImage.reset(new Image(imgSrc)); //修改副本
++pNew->imageChanges;
swap(pImpl, pNew);//置换数据
}
copy and swap策略虽然做出“全有或全无”改变的一个好办法，但一般而言并不保证整个函数有强烈的异常安全性。
如someFunc。使用copy-and-swap策略，但函数还包括对另外连个函数f1和f2的调用：
void somefunc()
{
…
f1();
f2();
…
}
显然，如果f1或f2的异常安全性比“强烈保证”低，就很难让someFunc成为“强烈异常安全”。如果f1和f2都是“强烈异常安全”，情况并不因此好转。毕竟，如果f1圆满结束，程序状态在任何方面都有可能有所改变，因此如果f2随后抛出异常，程序状态和someFunc被调用前并不相同，甚至当f2没有改变任何东西时也是如此。
问题出现在“连带影响”，如果由函数只操作局部状态，便相对容易的提供强烈保证，但是函数对“非局部性数据”有连带影响时，提供强烈保证就困难的多。例如，如果调用f1带来的影响是某个数据库被改动了，那就很难让someFunc具备强烈安全性。另一个主题是效率。copy-and-swap得好用你可能无法（或不愿意）供应的时间和空间。所以，“强烈保证”并不是在任何时候都显得实际。
当“强烈保证”不切实际时，你就必须提供“基本保证”。
你应该挑选“现实可操作”条件下最强烈等级，只有当你的函数调用了传统代码，才别无选择的将它设为“无任何保证”。
请记住：
1.异常安全函数即使发生异常也不会泄露资源或允许任何数据结构败坏。这样的函数区分为三种可能的保证：基本型、强烈型、不抛异常型。
2.“强烈保证”往往能够以copy-and-swap实现出来，但“强烈保证”并非对所有函数都可实现或具备现实意义。
3.函数提供的“异常安全保证”通常最高只等于其所调用之各个函数的“异常安全保证”中的最弱者。
