C/C++编程：慎用异常规格

Myth丶恋晨 2023-01-12 11:41 139阅读 0赞

特性**异常规格**可以使得代码更容易理解，因为它明确描述了一个函数可以抛出什么样的异常。但它不只是一个有趣的注释。编译器在编译时有时能够检测到异常规格的不一致。而且如果一个函数抛出一个不在异常规格范围内的异常，系统在运行时能够检测出这个错误，然后一个特殊函数unexpected将被自动调用。unexpected缺省行为是调用函数terminate，而terminate缺省的行为是调用函数abort，所以一个违反异常规格的程序的缺省行为是halt(停止允许)。在激活的栈中的局部变量没有被释放，因为abort在关闭程序时不进行这样的清除操作。对异常规格的触发变成了一场不应该发生的灾难

不幸的是，我们很容易就能够编写出导致这种灾难的函数，编译器仅仅部分的检测异常的使用是否与异常规格保持一致。A函数调用B函数，但因为B函数可能抛出一个不在A函数异常规格之内的异常，这个函数调用就违反了A函数的异常规格。编译器不会对此种情况进行检测，并且语言标准也禁止编译器拒绝这种调用方式（尽管可以显式警告）

比如函数f1没有声明异常规格，这样的函数就可以抛出任何种类的异常：

extern void f1();                  // 可以抛出任意的异常

假设有一个函数f2通过它的异常规格来声明其只能抛出int类型的异常：

void f2() throw(int);

f2调用f1是非常合法的，即使f1可能抛出一个违反f2异常规格的异常：

void f2() throw(int)
    {
      ...
    
      f1();                  // 即使f1可能抛出不是int类型的
                             //异常，这也是合法的。
      ...
    }

当带有异常规格的新代码与没有异常规格的老代码整合在一起工作时，这种灵活性就显得很重要。

因为你的编译器允许你调用一个函数，其抛出的异常与发出调用的异常规格不一致，并且这样的调用肯恩恶搞导致你的程序执行被终止，所以在编写软件时应该采取措施把这种不一致减少到最小。一种好方法是避免在带有类型参数的模板内使用异常规则。比如下面这种模板，它好像不能抛出任何异常

// a poorly designed template wrt exception specifications
    template<class T>
    bool operator==(const T& lhs, const T& rhs) throw()
    {
      return &lhs == &rhs;
    }

这个模板为所有类型定义了一个操作符函数operator==。对于任意一对类型相同的对象，如果对象有一样的地址，该函数返回true，否则返回false。

这个模板包含的异常规格表示模板生成的函数不能抛出异常。但是实际上调用时operator&可能抛出异常。这就违反了我们的异常规格，使得程序控制跳转到unexpected

上面例子是一种更一般问题的特例，这个更一般问题也就是没有版本知道某种模板类型参数抛出什么样的异常。我们几乎不可能为一个模板提供一个有意义的异常规格。因为模板总是采用不同的方法使用类型参数。解决方法只能是**模板和异常规格不要混合使用**

能够避免调用unexpected函数的第二个方法是**如果在一个函数内调用其它没有异常规格的函数时应该去除这个函数的异常规格**。这很容易理解，但是实际中容易被忽略。比如允许用户注册一个回调函数：

// 一个window系统回调函数指针
    //当一个windows系统事件发生时
    typedef void (*CallBackPtr)(int eventXLocatin, int eventYLoaction, void *dataToPassBack);
    
    //windows系统类，含有回调函数指针，该回调函数能被windows系统客户注册
    class CallBack{
    public:
        CallBack(CallBackPtr fPtr, void *dataToPassBack)
            :func(fPtr), data(dataToPassBack) {}
    
        void makeCallBack(int eventXLoaction, int eventYLocation) const throw();
    private:
        CallBackPtr func;  
        void *data;
    };
    
    //为了实现回调函数，我们调用注册函数，事件的坐标和注册数据作为函数参数
    void CallBack::makeCallBack(int eventXLocation,int eventYLocation) const throw()
    {
      func(eventXLocation, eventYLocation, data);
    }

这里在makeCallBack内调用func，要冒违反异常规格的风险，因为无法知道func会抛出什么类型的异常。

解决方法是：在CallBackPtr typedef种采用更严格的异常规格：

typedef void (*CallBackPtr)(int eventXLocation,   int eventYLocation, void *dataToPassBack) throw();

这样定义typedef后，如果注册一个可能会抛出异常的callBack函数将是非法的。

/ 一个没有异常规格的回调函数
    void callBackFcn1(int eventXLocation, int eventYLocation, void *dataToPassBack);
    
    void *callBackData;
    
    ...
    
    CallBack c1(callBackFcn1, callBackData); //错误！callBackFcn1可能 抛出异常
    
    //带有异常规格的回调函数
    void callBackFcn2(int eventXLocation, int eventYLocation, void *dataToPassBack) throw();
    
    CallBack c2(callBackFcn2, callBackData);// 正确，callBackFcn2

避免调用unexpected的第三个方法是**处理系统本身抛出的异常**。这些异常中最常见的是bad\_alloc，当内存分配失败时它被operator new 和operator new\[\]抛出（参见条款M8）。如果你在函数里使用new操作符（还参见条款M8），你必须为函数可能遇到bad\_alloc异常作好准备。

有时直接处理unexpected异常比防止它们被抛出要简单。例如你正在编写一个软件，精确地使用了异常规格，但是你必须从没有使用异常规格的程序库中调用函数，要防止抛出unexpected异常是不现实的，因为这需要改变程序库中的代码。

虽然防止抛出unexpected异常是不现实的，但是C++允许你用其它不同的异常类型替换unexpected异常，你能够利用这个特性。例如你希望所有的unexpected异常都被替换为UnexpectedException对象。你能这样编写代码：

class UnexpectedException {};          // 所有的unexpected异常对象被替换为这种类型对象
    
    void convertUnexpected()               // 如果一个unexpected异常被 抛出，这个函数被调用
    {                                      
          throw UnexpectedException(); 
    }

通过用convertUnexpected函数替换缺省的unexpected函数，来使上述代码开始运行：

set_unexpected(convertUnexpected);

当你这么做了以后，一个unexpected异常将触发调用convertUnexpected函数。Unexpected异常被一种UnexpectedException新异常类型替换。如果被违反的异常规格包含UnexpectedException异常，那么异常传递将继续下去，好像异常规格总是得到满足。（如果异常规格没有包含UnexpectedException，terminate将被调用，就好像你没有替换unexpected一样）

另一种把unexpected异常转变成知名类型的方法是替换unexpected函数，让其重新抛出当前异常，这样异常将被替换为bad\_exception。你可以这样编写：

void convertUnexpected()          // 如果一个unexpected异常被抛出，这个函数被调用
    {                                 
      throw;                          // 它只是重新抛出当前异常
    }                                 
    
    set_unexpected(convertUnexpected);  // 安装 convertUnexpected做为unexpected的替代品

如果这么做，你应该在所有的异常规格里包含bad\_exception（或它的基类，标准类exception）。你将不必再担心如果遇到unexpected异常会导致程序运行终止。任何不听话的异常都将被替换为bad\_exception，这个异常代替原来的异常继续传递。

到现在你应该理解异常规格能导致大量的麻烦。编译器仅仅能部分的检测它们的使用是否一致，在模板种使用它们会有问题，一不小心就很容易被违反，并且在缺省的情况下它们被违反会导致程序终止运行。另一个缺点是它们能够导致unexpected被触发，即使一个high-level调用者准备处理被抛出的异常。看个例子：

class Session {                  // for modeling online
    public:                          // sessions
      ~Session();
      ...
    private:
      static void logDestruction(Session *objAddr) throw();
    };
    
    Session::~Session()
    {
      try {
        logDestruction(this);
      }
      catch (...) {  }
    }

session的析构函数调用logDestruction记录有关session对象被释放的信息，它明确地要捕获从logDestruction抛出的所有异常。但是logDestruction的异常规格表示其不抛出任何异常。现在假设被logDestruction调用的函数抛出了一个异常，而logDestruction没有捕获。我们不会期望发生这样的事情，但正如我们所见，很容易就会写出违反异常规格的代码。当这个异常通过logDestruction传递出来，unexpected将被调用，缺省情况下将导致程序终止执行。这是一个正确的行为，但这是session析构函数的作者所希望的行为么？作者想处理所有可能的异常，所以好像不应该不给session析构函数里的catch块执行的机会就终止程序。如果logDestruction没有异常规格，这种事情就不会发生（一种防止的方法是如上所描述的那样替换unexpected）。

以全面的角度去看待异常规格是非常重要的（异常规格可以作为一个指导性文档也可是异常使用的强制约束机制）。它们提供了优秀的文档来说明一个函数抛出异常的种类，并且在违反它的情况下，会有可怕的结果，程序被立即终止，在缺省时它们会这么做。同时编译器只会部分地检测它们的一致性，所以他们很容易被不经意地违反。而且他们会阻止high-level异常处理器来处理unexpected异常，即使这些异常处理器知道如何去做。

**综上所述，异常规格是一个应被审慎使用的特性。在把它们加入到你的函数之前，应考虑它们所带来的行为是否就是你所希望的行为。**