首页 > 代码库 > 条款29:为“异常安全”而努力是值得的

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

资源、数据、状态

http://blog.csdn.net/u013540854/article/details/30721675

结论1:异常安全函数即使发生异常也不会泄漏资源或允许任何数据结构败坏。这样的函数区分为三种可能的保证:基本型、强烈型、不抛异常型。

"异常安全“有两个条件:不泄漏任何资源和不允许数据败坏。解决资源泄漏问题可用对象管理资源。对于数据败坏,异常安全函数提供三个保证:

基本承诺:如果异常被抛出,程序内的任何事物仍然保持在有效状态下。没有任何对象或数据结构会因此而败坏,所有对象都处于一种内部前后一致的状态。然而程序的现实状态(exact state)恐怕不可预料,程序有可能处于任何状态,只要那是个合法状态。

强烈保证:如果异常被抛出,程序状态不改变。调用这样的函数需有这样的认知:如果函数成功,就是完全成功,如果函数失败,程序会回复到”调用函数之前“的状态。

不抛掷保证:承诺绝不抛出异常,因为它们总是能够完成它们原先承诺的功能。作用于内置类型身上的所有操作都提供不抛掷保证。

结论2:”强烈保证“往往能够以copy-and-swap实现出来,但“强烈保证”并非对所有函数都可实现或具备现实意义。

copy-and-swap原则很简单:为打算修改的对象(原件)做一份副本,然后在那副本身上做一切必要修改。若有任何修改动作抛出异常,原对象仍保持未改变状态。待所有改变都成功后,再将修改过的那个副本和原对象在一个不抛出异常的操作中置换。

实际上通常将所有“隶属对象的数据”从原对象放进另一个对象内,然后赋予原对象一个指针,指向那个所谓的实现对象(即副本)。这种手法被称为pimpl idiom。

如果函数只操作局部状态,便相对容易提供强烈保证。但当函数对“非局部数据”有连带影响时,提供强烈保证就困难得多。另一个在提供强烈保证时需要考虑的主题是效率。当“强烈保证”不切实际时,就必须提供“基本保证"。

结论3:函数提供的“异常安全保证”通常最高只等于其所调用之各个函数的“异常安全保证”中的最弱者。

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