C++ 异常处理

前言：
异常处理是C++的一项语言机制，用于在程序中处理异常事件。异常事件在C++中表示为异常对象。异常事件发生时，程序使用throw关键字抛出异常表达式，抛出点称为异常出现点，由操作系统为程序设置当前异常对象，然后执行程序的当前异常处理代码块，在包含了异常出现点的最内层的try块，依次匹配catch语句中的异常对象（只进行类型匹配，catch参数有时在catch语句中并不会使用到）。若匹配成功，则执行catch块内的异常处理语句，然后接着执行try...catch...块之后的代码。如果在当前的try...catch...块内找不到匹配该异常对象的catch语句,则由更外层的try...catch...块来处理该异常；如果当前函数内所有的try...catch...块都不能匹配该异常，则递归回退到调用栈的上一层去处理该异常。如果一直退到主函数main()都不能处理该异常，则调用系统函数terminate()终止程序。

一：C/C++中的异常处理
增强错误恢复能力是提高代码健壮性的最有力的途径之一，C语言中采用的错误处理方法被认为是紧耦合的，函数的使用者必须在非常靠近函数调用的地方编写错误处理代码，这样会使得其变得笨拙和难以使用。C++中引入了异常处理机制，这是C++的主要特征之一，是考虑问题和处理错误的一种更好的方式。使用错误处理可以带来一些优点，如下:
·        错误处理代码的编写不再冗长乏味，并且不再和正常的代码混合在一起，程序员只需要编写希望产生的代码，然后在后面某个单独的区段里编写处理错误的嗲吗。多次调用同一个函数，则只需要某个地方编写一次错误处理代码。
·        错误不能被忽略，如果一个函数必须向调用者发送一次错误信息。它将抛出一个描述这个错误的对象。
传统的错误处理和异常处理
在讨论异常处理之前，我们先谈谈C语言中的传统错误处理方法，这里列举了如下三种:
·        在函数中返回错误，函数会设置一个全局的错误状态标志。
·        使用信号来做信号处理系统，在函数中raise信号，通过signal来设置信号处理函数，这种方式耦合度非常高，而且不同的库产生的信号值可能会发生冲突
·        使用标准C库中的非局部跳转函数 setjmp和longjmp

（1） setjmp和longjmp————C 语言中的长跳转
非局部跳转语句---setjmp和longjmp函数。非局部指的是，这不是由普通C语言goto，语句在一个函数内实施的跳转，而是在栈上跳过若干调用帧，返回到当前函数调用路径上的某一个函数中。
#include <setjmp.h>
Int setjmp(jmp_buf  env);
       返回值：若直接调用则返回0，若从longjmp调用返回则返回非0值的longjmp中的val值
Void longjmp(jmp_buf env,int val);
        调用此函数则返回到语句setjmp所在的地方，其中env 就是setjmp中的 env，而val 则是使setjmp的返回值变为val。

        当检查到一个错误时,则以两个参数调用longjmp函数，第一个就是在调用setjmp时所用的env，第二个参数是具有非0值的val，它将成为从setjmp处返回的值。使用第二个参数的原因是对于一个setjmp可以有多个longjmp。

 #include <iostream> 
 #include <setjmp.h> 
 jmp_buf static_buf; //用来存放处理器上下文，用于跳转 
 
void do_jmp() 
{ 
    //do something,simetime occurs a little error 
        //调用longjmp后，会载入static_buf的处理器信息，然后第二个参数作为返回点的setjmp这个函数的返回值 
         longjmp(static_buf,10);//10是错误码，根据这个错误码来进行相应的处理 
   } 
    
   int main() 
   { 
       int ret = 0; 
       //将处理器信息保存到static_buf中,并返回0，相当于在这里做了一个标记，后面可以跳转过来 
      if((ret = setjmp(static_buf)) == 0) { 
           //要执行的代码 
           do_jmp(); 
       } else {    //出现了错误 
           if (ret == 10) 
               std::cout << "a little error" << std::endl; 
      } 
  } 
错误处理方式看起来耦合度不是很高，正常代码和错误处理的代码分离了，处理处理的代码都汇聚在一起了。但是基于这种局部跳转的方式来处理代码，在 C++中却存在很严重的问题，那就是对象不能被析构，局部跳转后不会主动去调用已经实例化对象的析构函数。这将导致内存泄露的问题

（2）C++ 中的异常处理
异常处理是C++的一项语言机制，用于在程序中处理异常事件。异常事件在C++中表示为异常对象。异常事件发生时，程序使用throw关键字抛出异常表达式，抛出点称为异常出现点，由操作系统为程序设置当前异常对象，然后执行程序的当前异常处理代码块，在包含了异常出现点的最内层的try块，依次匹配catch语句中的异常对象（只进行类型匹配，catch参数有时在catch语句中并不会使用到）。若匹配成功，则执行catch块内的异常处理语句，然后接着执行try...catch...块之后的代码。如果在当前的try...catch...块内找不到匹配该异常对象的catch语句,则由更外层的try...catch...块来处理该异常；如果当前函数内所有的try...catch...块都不能匹配该异常，则递归回退到调用栈的上一层去处理该异常。如果一直退到主函数main()都不能处理该异常，则调用系统函数terminate()终止程序。

//示例代码：throw包含在外层函数的try块中
void registerScore(int score)
{
    if (score > 100 || score < 0)
        throw score; //throw语句被包含在外层main的try语句块中
    //将分数写入文件或进行其他操作
}
int main()
{
    int score=0;
    while (cin >> score)
    {
        try
        {
            registerScore(score);
        }
        catch (int score)
        {
            cerr << "你输入的分数数值有问题，请重新输入！";
            continue;
        }
    }
}

二：C++中的异常类
异常对象是一种特殊的对象，编译器依据异常抛出表达式复制构造异常对象，这要求抛出异常表达式不能是一个不完全类型（一个类型在声明之后定义之前为一个不完全类型。不完全类型意味着该类型没有完整的数据与操作描述），而且可以进行复制构造，这就要求异常抛出表达式的复制构造函数（或移动构造函数）、析构函数不能是私有的。
异常对象不同于函数的局部对象，局部对象在函数调用结束后就被自动销毁，而异常对象将驻留在所有可能被激活的catch语句都能访问到的内存空间中，也即上文所说的TIB。当异常对象与catch语句成功匹配上后，在该catch语句的结束处被自动析构。
在函数中返回局部变量的引用或指针几乎肯定会造成错误，同样的道理，在throw语句中抛出局部变量的指针或引用也几乎是错误的行为。如果指针所指向的变量在执行catch语句时已经被销毁，对指针进行解引用将发生意想不到的后果。
throw出一个表达式时，该表达式的静态编译类型将决定异常对象的类型。所以当throw出的是基类指针的解引用，而该指针所指向的实际对象是派生类对象，此时将发生派生类对象切割。
除了抛出用户自定义的类型外，C++标准库定义了一组类，用户报告标准库函数遇到的问题。这些标准库异常类只定义了几种运算，包括创建或拷贝异常类型对象，以及为异常类型的对象赋值。

三：栈展开、RAII
其实栈展开已经在前面说过，就是从异常抛出点一路向外层函数寻找匹配的catch语句的过程，寻找结束于某个匹配的catch语句或标准库函数terminate。这里重点要说的是栈展开过程中对局部变量的销毁问题。我们知道，在函数调用结束时，函数的局部变量会被系统自动销毁，类似的，throw可能会导致调用链上的语句块提前退出，此时，语句块中的局部变量将按照构成生成顺序的逆序，依次调用析构函数进行对象的销毁
但是这其中有一个隐含的问题：
int main()
{
    try
    {
        A * a= new A;
        throw *a;
    }
    catch (A a)
    {
        ;
    }
    getchar();
    return 0;
}
只是执行了两次析构函数，说明发生了内存泄露，RAII机制有助于解决这个问题，RAII（Resource acquisition is initialization，资源获取即初始化）。它的思想是以对象管理资源。为了更为方便、鲁棒地释放已获取的资源，避免资源死锁，一个办法是把资源数据用对象封装起来。程序发生异常，执行栈展开时，封装了资源的对象会被自动调用其析构函数以释放资源。C++中的智能指针便符合RAII。关于这个问题详细可以看《Effective C++》条款13.

四：异常机制与构造函数
异常机制的一个合理的使用是在构造函数中。构造函数没有返回值，所以应该使用异常机制来报告发生的问题。更重要的是，构造函数抛出异常表明构造函数还没有执行完，其对应的析构函数不会自动被调用，因此析构函数应该先析构所有所有已初始化的基对象，成员对象，再抛出异常。
C++类构造函数初始化列表的异常机制，称为function-try block。一般形式为：
myClass::myClass(type1 pa1)
    try:  _myClass_val (初始化值)
{
  /*构造函数的函数体 */
}
  catch ( exception& err )
{
  /* 构造函数的异常处理部分 */
};

五：异常机制与析构函数
C++不禁止析构函数向外界抛出异常，但析构函数被期望不向外界函数抛出异常。析构函数中向函数外抛出异常，将直接调用terminator()系统函数终止程序。如果一个析构函数内部抛出了异常，就应该在析构函数的内部捕获并处理该异常，不能让异常被抛出析构函数之外。可以如此处理：
若析构函数抛出异常，调用std::abort()来终止程序。
在析构函数中catch捕获异常并作处理。
关于具体细节，有兴趣可以看《Effective C++》条款08：别让异常逃离析构函数。

六：noexcept修饰符与noexcept操作符
noexcept修饰符是C++11新提供的异常说明符，用于声明一个函数不会抛出异常。编译器能够针对不抛出异常的函数进行优化，另一个显而易见的好处是你明确了某个函数不会抛出异常，别人调用你的函数时就知道不用针对这个函数进行异常捕获。在C++98中关于异常处理的程序中你可能会看到这样的代码：
void func() throw(int ,double ) {...}
void func() throw(){...}
这是throw作为函数异常说明，前者表示func（）这个函数可能会抛出int或double类型的异常，后者表示func()函数不会抛出异常。事实上前者很少被使用，在C++11这种做法已经被摒弃，而后者则被C++11的noexcept异常声明所代替：
void func() noexcept {...}
//等价于void func() throw(){...}
在C++11中，编译器并不会在编译期检查函数的noexcept声明，因此，被声明为noexcept的函数若携带异常抛出语句还是可以通过编译的。在函数运行时若抛出了异常，编译器可以选择直接调用terminate()函数来终结程序的运行，因此，noexcept的一个作用是阻止异常的传播,提高安全性.
上面一点提到了，我们不能让异常逃出析构函数，因为那将导致程序的不明确行为或直接终止程序。实际上出于安全的考虑，C++11标准中让类的析构函数默认也是noexcept的。 同样是为了安全性的考虑，经常被析构函数用于释放资源的delete函数，C++11也默认将其设置为noexcept。
noexcept也可以接受一个常量表达式作为参数，例如：
void func() noexcept(常量表达式);
常量表达式的结果会被转换成bool类型，noexcept(bool)表示函数不会抛出异常，noexcept(false)则表示函数有可能会抛出异常。故若你想更改析构函数默认的noexcept声明，可以显式地加上noexcept(false)声明，但这并不会带给你什么好处。

七：异常处理的性能分析
异常处理机制的主要环节是运行期类型检查。当抛出一个异常时，必须确定异常是不是从try块中抛出。异常处理机制为了完善异常和它的处理器之间的匹配，需要存储每个异常对象的类型信息以及catch语句的额外信息。由于异常对象可以是任何类型（如用户自定义类型），并且也可以是多态的，获取其动态类型必须要使用运行时类型检查（RTTI），此外还需要运行期代码信息和关于每个函数的结构。
当异常抛出点所在函数无法解决异常时，异常对象沿着调用链被传递出去，程序的控制权也发生了转移。转移的过程中为了将异常对象的信息携带到程序执行处（如对异常对象的复制构造或者catch参数的析构），在时间和空间上都要付出一定的代价，本身也有不安全性，特别是异常对象是个复杂的类的时候。
异常处理技术在不同平台以及编译器下的实现方式都不同，但都会给程序增加额外的负担，当异常处理被关闭时，额外的数据结构、查找表、一些附加的代码都不会被生成，正是因为如此，对于明确不抛出异常的函数，我们需要使用noexcept进行声明。