1. 异常安全的要求与案例问题
以PrettyMenu类的changeBackground函数为例：
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(imgSrc)抛出异常，会导致互斥体未解锁造成资源泄露，且bgImage指向已删除对象、imageChanges计数错误，数据结构恶化。
2. 异常安全保证类型
- 基本保证：若异常抛出，程序中所有内容处于合法状态，对象和数据结构未被破坏，所有类不变量满足，但程序精确状态可能不可预期。例如修改
changeBackground函数，异常抛出时PrettyMenu对象可能保留原背景图像或采用默认背景图像，客户无法预知。 - 强力保证：若异常抛出，程序状态不发生变化，函数要么完全成功，要么程序状态如同未调用该函数。如改进
changeBackground函数，将bgImage改为std::tr1::shared_ptr<Image>，调整语句顺序：
class PrettyMenu {...std::tr1::shared_ptr<Image> bgImage;...
};void PrettyMenu::changeBackground(std::istream& imgSrc) {Lock ml(&mutex);bgImage.reset(new Image(imgSrc)); ++imageChanges;
}
如此，基本能提供强力保证，但因imgSrc输入流读标记可能改变，实际只能提供基本保证。
- 不抛出保证：函数绝不抛出异常，内建类型操作通常提供此保证。例如
int a = 5 + 3;这类操作不会抛出异常。
3. 实现异常安全的策略 - copy - and - swap
通过 “copy and swap” 策略可实现强力保证，原理是先拷贝要改变的对象，在拷贝对象上完成改变，若过程中抛出异常，原对象不变，成功后将改变后的对象与原对象通过不抛出异常的操作交换。以PrettyMenu类采用 “pimpl idiom” 实现为例：
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);
}
4. 异常安全保证的限制因素
- 函数调用影响：若函数调用的其他函数未提供强力异常安全保证，自身也难以提供。如
someFunc调用f1和f2，若f1仅提供基本保证，someFunc为提供强力保证需复杂操作；若f1完成后f2抛出异常，即使f2未改变，程序状态也已不同。
void someFunc() {... f1();f2();...
}
- 副作用影响：函数副作用影响非局部数据时，提供强力保证困难。如
f1改变数据库，因数据库变化难以撤销，someFunc很难成为强力异常安全。 - 效率因素：“copy and swap” 需拷贝对象，可能耗费大量时间和空间，影响效率，导致难以对所有函数提供强力保证。
5. 总结与建议
编写异常安全代码时，应使用对象管理资源防止资源泄漏，为函数选择能提供的最强异常安全保证（基本、强力或不抛出），并文档化决策。若函数调用的其他函数不提供异常安全保证，自身也无法提供。虽遗留的非异常安全代码普遍存在，但编写新代码或修改现有代码时，应努力实现异常安全。
