More Exceptional C++中文版试读（异常安全议题及技术）

在现代C++程序设计中，对异常安全（exception safety）议题一无所知却想写出健壮的代码，这无异于痴人说梦。的确如此。

如果你在使用C++标准库，哪怕只是用到了new，你也得为异常做好准备。本章建立在Exceptional C++相应章节的基础上，并讨论了新的议题及相关技术，例如：std::uncaught_exception()是什么？它能帮助你写出更健壮的代码吗？异常安全影响到类的设计吗？或者，它可以只是作为事后的改进手段来使用吗？为什么要用管理者对象（manager objects）来封装资源所有权？为什么“资源获取才是初始化”的认识对于编写安全代码如此重要？

但首先还是让我们来热身一下，看一个有关异常安全的基本话题；这个话题对以下非常重要的C++基本概念进行了说明，并剖析了其更深层的含义：构造具有什么含义？什么是对象的生命期？

1. 请看下面这个类：

    // 例17-1

    //

    class C : private A

    {

      B b_;

    };

在C的构造函数中，如何捕捉从基类子对象（例如A）或成员对象（例如b_）的构造函数中抛出的异常？

2. 请看下面的代码：

    // 例17-2

    //

    {

      Parrot p;

    }

这个对象的生命期何时开始？何时结束？在对象的生命期之外，对象处于什么状态？最后，如果它的构造函数抛出了一个异常，那将意味着什么？

在C++中增加function try block这一特性后，函数可以捕获异常的范围稍微增大了一些。本条款的内容涉及：

·在C++中，对象构造与构造失败的含义；

·基类或成员子对象的构造函数抛出异常时，function try block可用于转化（而非抑制）这个异常。

方便起见，除非特别指出，本条款中的“成员”指的是“非静态的类数据成员”。

Function Try Block

1. 请看下面这个类：

    // 例17-1

    //

    class C : private A

    {

      B b_;

    };

在C的构造函数中，如何捕捉从基类子对象（例如A）或成员对象（例如b_）的构造函数中抛出的异常？

这正是function try block的用武之地：

    // 例17-1(a): 构造函数的function try block

    //

C::C()

try

      : A ( /*...*/ ) // 可选的初始化列表

      , b_( /*...*/ )

    {

    }

    catch( ... )

    {

      // 一旦A::A()或B::B()抛出异常，我们会来到这儿

      // 如果A::A()成功，然后B::B()抛出异常，

      // C++语言将保证，在到达本catch block

      // 之前，A::~A()会被调用，以摧毁已经创建

      // 的基类A子对象。

    }

然而，更有趣的问题是：你为什么会想到这么做？这个问题引出了本条款两大要点的第一个。

对象生命期与构造函数异常的含义

过一会儿，我们将回答一个问题，即，上面C的构造函数是否可以（或应该）吸收（absorb）A或B的构造函数产生的异常，从而完全不发出异常。在可以正确回答这个问题之前，我们需要完全了解对象生命期¹的概念，以及构造函数抛出异常的含义。

2. 请看下面的代码：

    // 例17-2

    //

    {

      Parrot p;

    }

这个对象的生命期何时开始？何时结束？在对象的生命期之外，对象处于什么状态？最后，如果它的构造函数抛出了一个异常，那将意味着什么？

让我们一次回答一个问题：

问：一个对象的生命期何时开始？

答：当它的构造函数成功执行完毕并正常返回之时。也就是说，当控制（control）抵达构造函数体的末尾之时，或执行完一个更早的return语句之时。

问：一个对象的生命期何时结束？

__________________

1. 为简化起见，我在这里所说的只是类型为class、具有构造函数的对象的生命期。

答：当它的析构函数开始执行之时。也就是说，当控制抵达析构函数体的开始处之时。

问：对象的生命期结束之后，对象处于什么状态？

答：我们的回答正如一位知名软件大师曾经表述的那样：在谈到一段类似的代码时，他将局部对象（local object）拟人化地称为“他”：

    // 例17-3

    //

    {

      Parrot& perch = Parrot();

    }

    // <-- 独白从这里开始

他并非日渐消瘦！他已经逝去！这只鹦鹉（Parrot）已经芳踪不再！他已经停止了生命！他已经死亡，去见他的造物者去了！他是死尸！被剥夺了生命，安静长眠！如果你没有把他放在枝头（perch），它已经命归黄土！[甚至更早，在这个代码块尾部之前]他的代谢过程已经作古！他离开了枝头！他已经撒手人寰，摆脱了尘世的烦恼，拉上了生命的帷幕，加入了唱师班，无影无踪！这是一只前世的鹦鹉（ex-Parrot）！

——Dr. M.Python, B.Math, MA.Sc., Ph.D. (CompSci)²

撇开玩笑不说，此处的重点在于：在生命期开始之前与生命期结束之后，对象的状态完全一样——没有对象存在。就是这样。这一结论将我们带到第二个重要问题前：

问：从构造函数中抛出异常意味着什么？

答：这意味着构造已经失败，对象从没存在过，它的生命期从没开始过。确实，报告构造失败——也就是说，无法正确构造出某种类型的有效对象——的唯一方法是抛出一个异常。（是的，有一条如今已经过时的编程规则是这么说的：“如果程序出了问题，可以将一个状态标志设为‘bad’，让调用者通过一个IsOK()函数去检查它”；后面，我会对此谈谈我的看法。）

顺便说一句，如果构造函数不成功，析构函数就永远不会被调用，其原因正在于此——没有东西可以摧毁。它无法死亡，因为它从来就未曾生存过。请注意，这样一来，“一个对象的构造函数抛出异常”这句话实际上具有矛盾性。这样一种东西甚至不能被称为一个前对象（ex-object）。它从没有生存过，从没有加入过对象家族。它是一个非对象（non-object）。

__________________

2. 向Monty Python致歉。

对于C++的构造函数模型，我们可以总结如下：

只会是二者之一：

a) 构造函数正常返回，即，控制抵达函数体的尾部，或者执行了一个return语句。这种情况下，对象真实存在。

b) 构造函数抛出异常后退出。这种情况下，对象不仅不会继续存在，而且，实际上它根本就从未作为一个对象存在过。

没有其它的可能性。具备了这些知识，我们就可以更好地应对下一条款中的问题了：可否吸收异常？