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

我怎么发现最近记录的这几条原则的叙述内容都很冗长无法一眼两眼就能看懂。
作者首先从一个类似于从MFC取材的例子，就是更换背景色的一个功能，并且它是在多线程环境下工作的。这个功能的具体实现首先加上互斥锁，删除旧背景，记录图像更改次数，生成最新的背景图片，去掉互斥锁。然而，这种步骤并不符合异常安全性。
因为作者说这种实现不符合异常安全性，而所谓的异常安全性，具体来讲包括2个方面，它们是：
1、不泄露任何资源：上例很难做到，因为咋生成新的背景图片这一步，如果出现异常，程序就不会继续往下执行，那么互斥锁就永远不会解锁，那么占用的资源就会被释放，那么就会造成资源泄露。
怎样做到不泄露呢？条款14说过就是用资源管理类。这一点有点区别，在不使用资源管理类时使用互斥锁下图这样的：

而使用资源管理类机制之后是如下的情形：

Ml是Lock的一个对象，这样它有自己的构造函数和析构函数，这就避免了资源泄露，而且这不仅使程序较短而且还免去了写unlock，降低了程序的复杂性也就有效地降低了出错的可能性。
2、不允许数据被损坏：这个词可以理解为数据的实际行为不符合数据预期的行为，而用于表征数据行为的值又没有如实地反映数据的行为。在本例中就是实际new的图像并未成功，但是记录更改次数的变量记录了这次错误的new行为，而作为左值的指针实际指向的却是空值。
那么如何处理数据败坏呢？需要做到3点，1、基本承诺；2、强烈保障；3、不抛掷异常保障。
1、基本承诺：在程序内抛出异常前后程序内部的各种数据仍然保持有效，不被败坏。
2、强烈保证：如果程序抛出异常，程序原正常状态不改变。函数成功就完全成功，不成功则会倒退回到原先正常的状态。
3、不抛掷异常保障：程序本身绝对不会抛出异常。这种程序主要是针对内置类型。

关于第3点，作者举了一个空白异常明细的函数，如下图所示：

所谓异常明细直到现在我所学的C++知识而言，我还不清楚它就是是指啥，但是从这张图片来看它应该是说throw()里面的参数吧。作者意在说明决定函数是否正确、高效、可移植的不是函数原型而是函数的具体实现。所以你要想使一个函数不抛出异常，那你就好好去实现吧。
异常安全码？这是个啥东东？它代表以上三中保障之一，你必须为你所写的函数提供一个异常安全码，到目前为止还没有一个函数不需要异常安全码。
再细化一下的话，你会发现提供那些不抛出异常的函数是很难做到的，所以异常安全码的取值往往在前两种情况，即，基本保障和强烈保障。其中最好的保障就是强烈保障，不过好像强烈保障中包含了基本保障。
再以本文中提供的例子进行解析。为了保证new的异常安全性作者推荐使用智能指针，而为了解决基本保障的问题作者决定调整语句次序。具体在本例就是因为计数器是用来记录背景图像真的被变更了才加1的，所以它必须放在new语句下面而不是上面，因为只有放在下面这个新的背景才是真的被new出来了。
不过仅仅这样做也会产生一个问题，那就是在new的过程中构造函数仍然可能抛出异常，而这种异常仍然可能改变程序。在这里作者有提供了一种手段，那就是swap and copy方法。道理很简单，就是在原来对象的副本身上进行改变，如果改变没问题就是用那个副本，否则由于原来的对象还在那你还可以使用原来的对象。而又由于交换对象本身内容费时又费力，所以在这里最好采用交换两对象的指针，也就是以前提过的pimpl原则。很有特点的是，在智能指针中new对象是一个struct，这是由于struct的默认访问属性是private，当然还有其他的原因但是在这里我的认知还体会不到。
不过这还不足以提供强烈异常安全性保障。作者就此举了一个例子，那就是在一个函数中又调用了另外两个函数的例子。不仅仅是在这两个函数不提供异常安全性保障的情况下，就算是这俩函数都提供了异常安全性保障，并且是强烈的异常安全性保障的情况下，仍然无法确保主调函数也是强烈异常安全的。因为这俩函数如果发生了异常，它改动了非局部性的数据，比如说数据库，即便这两函数被恢复了回来，但是外部的数据还是被改变了，那么其他的用户就极有可能使用因发生异常而被改动的那些不应该被改动的数据。
还有一个问题就是swap and copy策略的效率问题。因为这个策略是需要一个元对象的副本的，制作这个副本怎么着的也需要一定时间吧，如果原对象很大那你这个副本的制作时间花销也小不了啊。因此从这一点来讲任何时候都提供强烈的异常安全性保障是不切实际的，这时你只能提供基本保障了，但是这不是你不提供异常安全性保障的理由。
总结一下作者的观点就是一下3点：
1、就是那三种异常安全性保障了；
2、强烈保障能通过swap and copy策略来实现，但是并不是所有场合都适用于强烈安全性保障；
3、函数的异常安全性等于函数内部函数异常安全性保障中的最弱者。