设为首页 加入收藏

TOP

(Effective C++) Item 29:争取异常安全的代码(一)
2017-06-23 10:23:24 】 浏览:466
Tags:Effective Item 29: 争取 异常 安全 代码

(Effective C++) Item 29:争取异常安全的代码,异常安全(Exception safety)有点像怀孕(pregnancy)……但是,请把这个想法先控制一会儿。我们还不能真正地议论生育(reproduction),直到我们排除万难渡过求爱时期
(courtship)。(此段作者使用的 3 个词均有双关含义,pregnancy 也可理解为富有意义,reproduction 也可理解为再现,再生,courtship 也可理解为争取,谋求。为了与后面的译文对应,故按照现在的译法。——译者注)

假设我们有一个类,代表带有背景图像的 GUI 菜单。这个类被设计成在多线程环境中使用,
所以它有一个用于并行控制(concurrency control)的互斥体(mutex):

class PrettyMenu { public: ... void changeBackground(std::istream& imgSrc); // change background ... // image private: Mutex mutex; // mutex for this object Image *bgImage; // current background image int imageChanges; // # of times image has been changed };

考虑这个 PrettyMenu 的 changeBackground 函数的可能的实现:

void PrettyMenu::changeBackground(std::istream& imgSrc) { lock(&mutex); // acquire mutex (as in Item 14) delete bgImage; // get rid of old background ++imageChanges; // update image change count bgImage = new Image(imgSrc); // install new background unlock(&mutex); // release mutex }

从异常安全的观点看,这个函数烂到了极点。异常安全有两条要求,而这里全都没有满足。
当一个异常被抛出,异常安全的函数应该:
没有资源泄露。上面的代码没有通过这个测试,因为如果 "new Image(imgSrc)" 表达式产生一个异常,对 unlock 的调用就永远不会执行,而那个互斥体也将被永远挂起。
不允许数据结构恶化。如果 “new Image(imgSrc)” 抛出异常,bgImage 被遗留下来指向一个被删除对象。另外,尽管并没有将一张新的图像设置到位,imageChanges 也已经
被增加。(在另一方面,旧的图像被明确地删除,所以我料想你会争辩说图像已经被“改变”了。)
规避资源泄露问题比较容易,因为Item 13 解释了如何使用对象管理资源,而 Item 14 又引进
了 Lock 类作为一种时尚的确保互斥体被释放的方法:

void PrettyMenu::changeBackground(std::istream& imgSrc) { Lock ml(&mutex); // from Item 14: acquire mutex and // ensure its later release delete bgImage; ++imageChanges; bgImage = new Image(imgSrc); }

关于像 Lock 这样的资源管理类的最好的事情之一是它们通常会使函数变短。看到对 unlock的调用不再需要了吗?作为一个一般的规则,更少的代码就是更好的代码。因为在改变的时候这样可以较少误入歧途并较少产生误解。
随着资源泄露被我们甩在身后,我们可以把我们的注意力集中到数据结构恶化。在这里我们有一个选择,但是在我们能选择之前,我们必须先面对定义我们的选择的术语。
异常安全函数提供下述三种保证之一:

函数提供基本保证(the basic guarantee),允诺如果一个异常被抛出,程序中剩下的每一件东西都处于合法状态。没有对象或数据结构被破坏,而且所有的对象都处于内部调和状态(所有的类不变量都被满足)。然而,程序的精确状态可能是不可预期的。例如,我们可以重写 changeBackground,以致于如果一个异常被抛出,PrettyMenu 对象可以继续保留原来的背景图像,或者它可以持有某些缺省的背景图像,但是客户无法预知到底是哪一个。(为了查明这一点,他们大概必须调用某个可以告诉他们当前背景图
像是什么的成员函数。) 函数提供强力保证(the strong guarantee),允诺如果一个异常被抛出,程序的状态不会发生变化。调用这样的函数在感觉上是极其微弱的,如果它们成功了,它们就完全成功,如果它们失败了,程序的状态就像它们从没有被调用过一样。
与提供强力保证的函数一起工作比与只提供基本保证的函数一起工作更加容易,因为调用提供强力保证的函数之后,仅有两种可能的程序状态:像预期一样成功执行了函数,或者继续保持函数被调用时当时的状态。与之相比,如果调用只提供基本保证的函数引发了异常,程序可能存在于任何合法的状态。 函数提供不抛出保证(the nothrow guarantee),允诺决不抛出异常,因为它们只做它们答应要做的。所有对内建类型(例如,ints,指针,等等)的操作都是不抛出(nothrow)的(也就是说,提供不抛出保证)。这是异常安全代码中必不可少的基础构
件。
假定一个带有空的异常规格(exception specification)的函数是不抛出的似乎是合理的,但这不一定正确的。例如,考虑这个函数:
int doSomething() throw(); // note empty exception spec.

这并不是说 doSomething 永远不会抛出异常;而是说如果 doSomething 抛出一个异常,
它就是一个严重的错误,应该调用 unexpected 函数 [1]。实际上,doSomething 可能根本不提供任何异常保证。一个函数的声明(如果有的话,也包括它的异常规格(exception specification))不能告诉你一个函数是否正确,是否可移植,或是否高效,而且,即便有,它也不能告诉你它会提供哪一种异常安全保证。所有这些特性都由函数的实现决定,而不是它的声明能决定的。
[1] 关于 unexpected 函数的资料,可以求助于你中意的搜索引擎或包罗万象的 C++ 课本。(你或许有幸搜到 set_unexpected,这个函数用于指定 unexpected 函数。)

异常安全函数必须提供上述三种保证中的一种。如果它没有提供,它就不是异常安全的。于是,选择就在于决定你写的每一个函数究竟要提供哪种保证。除非要处理遗留下来的非异常安全的代码(本 Item 稍后我们要讨论这个问题),只有当你的最高明的需求分析团队为你的应用程序识别出的一项需求就是泄漏资源以及运行于被破坏的数据结构之上时,不提供异常安全保证才能成为一个选项。
作为一个一般性的规则,你应该提供实际可达到的最强力的保证。从异常安全的观点看,不抛出的函数(nothrow functions)是极好的,但是在 C++ 的 C 部分之外部不调用可能抛出异常的函数简直就是寸步难行。使用动态分配内存的任何东西(例如,所有的 STL 容器)如果不能

首页 上一页 1 2 3 下一页 尾页 1/3/3
】【打印繁体】【投稿】【收藏】 【推荐】【举报】【评论】 【关闭】 【返回顶部
上一篇三种工厂模式的分析以及C++实现 下一篇Eclipse CDT环境下编写、调试、运..

最新文章

热门文章

Hot 文章

Python

C 语言

C++基础

大数据基础

linux编程基础

C/C++面试题目