1. 灾难现场：一个“不安全”的函数
假设我们要在多线程环境下更换一个 GUI 菜单的背景图片：
class PrettyMenu {
public:void changeBackground(std::istream& imgSrc) {lock(&mutex); // 1. 获取互斥锁delete bgImage; // 2. 删除旧图片++imageChanges; // 3. 增加修改次数bgImage = new Image(imgSrc); // 4. 创建新图片 (可能抛出异常！)unlock(&mutex); // 5. 释放互斥锁}private:Mutex mutex;Image* bgImage;int imageChanges;
};
这一段代码是灾难性的。 如果第 4 步 new Image(imgSrc) 抛出了异常（比如内存不足或图片格式错误）：
- 资源泄露：
unlock永远不会被执行，导致死锁。 - 数据败坏 (A)：
bgImage已经被删除了，指向无效内存，但新图片还没赋值。这是一个悬空指针。 - 数据败坏 (B)：
imageChanges已经被加 1 了，但实际上图片并没有更换成功。逻辑状态不一致。
2. 第一步救赎：资源管理 (RAII)
要解决资源泄漏问题，很简单，遵循 Item 13（使用对象管理资源）：用智能指针管理内存，用 LockGuard 管理锁。
void changeBackground(std::istream& imgSrc) {LockGuard lock(&mutex); // 自动上锁，函数退出（无论是否异常）自动解锁// 依然有问题：数据一致性delete bgImage; ++imageChanges; bgImage = new Image(imgSrc);
}
现状： 即使异常发生，锁也会被解开。资源安全了，但数据依然是坏的（旧图没了，新图没来，计数器却加了）。
3. 核心概念：异常安全的三重境界 (Three Guarantees)
Scott Meyers 提出了著名的异常安全等级，你必须明确你的函数能提供哪一级别的保证：
级别 1：基本承诺 (Basic Guarantee)
- 承诺： 如果异常抛出，程序内的任何事物都保持在有效状态。没有任何对象损坏，没有任何指针悬空。
- 代价： 程序的具体状态可能是不可预知的。比如图片换失败了，可能是旧图，也可能是个默认的“空白图”，但绝不会是野指针。
级别 2：强烈承诺 (Strong Guarantee) —— 类似数据库事务
- 承诺： 要么成功，要么回到原点。 (Commit or Rollback)。
- 效果： 如果函数抛出异常，程序状态就像该函数从未被调用过一样。
- 地位： 这是我们最想达到的理想境界。
级别 3：不抛掷承诺 (Nothrow Guarantee)
- 承诺： 绝不抛出异常。
- 场景： 作用于内置类型（int, 指针）的操作，以及析构函数和
swap函数。这是构建异常安全大厦的基石。
4. 终极技法：Copy-and-Swap (实现强烈承诺)
如何最简单地实现“强烈承诺”？策略是：先在旁边做个副本修改，改好了再无缝替换。
这种技术被称为 Copy-and-Swap（先拷贝，再交换）。
重构后的代码：
class PrettyMenu {// 使用智能指针，自动管理内存std::shared_ptr<Image> bgImage; int imageChanges;Mutex mutex;public:void changeBackground(std::istream& imgSrc) {LockGuard lock(&mutex); // 1. 资源安全：自动管理锁// 2. 准备阶段 (Prepare)：在副本上操作// 创建一个新的 shared_ptr，指向新的 Image。// 如果这里 new 抛出异常，原有的 bgImage 根本没动，状态完美回滚。std::shared_ptr<Image> pNew(new Image(imgSrc)); // 3. 提交阶段 (Commit)：不抛异常的操作// 只有当 pNew 成功创建后，才进行交换。bgImage.swap(pNew); // swap 保证不抛异常 (Nothrow)++imageChanges;}
};
为什么这能实现 Strong Guarantee？
- 如果在
new Image时抛出异常：bgImage还没被碰过，imageChanges也没加。函数退出，锁释放。一切如初。 swap操作只是交换内部指针，极快且绝不抛出异常。- 旧的图片会在
pNew离开作用域时（即函数结束时）自动析构。
5. 现实的权衡 (Trade-offs)
既然“强烈承诺”这么好，为什么不让所有函数都支持它？
- 性能开销： Copy-and-Swap 需要拷贝一个副本。如果你在修改一个巨大的
vector或数据库，拷贝一份的代价太大了。 - 连带效应： 如果你的函数调用了别人的函数，而别人的函数只提供“基本承诺”，那你通常很难将其升级为“强烈承诺”。
结论：
- 必须提供：基本承诺 (Basic Guarantee)。这是底线。
- 尽力提供：强烈承诺 (Strong Guarantee)。如果是 UI 状态、关键逻辑，尽量用 Copy-and-Swap 实现。
- 绝不提供：没有任何保证的代码。那是 Bug 的温床。
总结 (Summary)
- 异常安全不是关于
catch，而是关于cleanup和consistency。 - 两大法则： 不泄露资源（用 RAII），不破坏数据结构。
- 三大等级： 基本承诺（有效但不确定）、强烈承诺（事务性回滚）、不抛掷承诺。
- 实战策略： 使用 Copy-and-Swap 技术是实现强烈承诺的最强手段——先在副本上修改，成功后再交换。