C++异常处理

C++异常处理（try catch throw）

程序运行时常会碰到一些异常情况，例如：

• 做除法的时候除数为 0；
• 用户输入年龄时输入了一个负数；
• 用 new 运算符动态分配空间时，空间不够导致无法分配；
• 访问数组元素时，下标越界；打开文件读取时，文件不存在。

这些异常情况，如果不能发现并加以处理，很可能会导致程序崩溃。

一发现异常情况就立即处理未必妥当，因为在一个函数执行过程中发生的异常，在有的情况下由该函数的调用者决定如何处理更加合适。尤其像库函数这类提供给程序员调用，用以完成与具体应用无关的通用功能的函数，执行过程中贸然对异常进行处理，未必符合调用它的程序的需要。

鉴于上述原因， 引入了异常处理机制。其基本思想是：函数 A 在执行过程中发现异常时可以不加处理，而只是“拋出一个异常”给 A 的调用者，假定为函数 B。

如果一层层的函数都不处理异常，异常最终会被拋给最外层的 main 函数。main 函数应该处理异常。如果main函数也不处理异常，那么程序就会立即异常地中止。

1、C++异常处理基本语法

C++ 通过 throw 语句和 try…catch 语句实现对异常的处理。throw 语句的语法如下：

throw 表达式;

该语句拋出一个异常。异常是一个表达式，其值的类型可以是基本类型，也可以是类。
try…catch 语句的语法如下：

try {
    语句组
}
catch(异常类型) {
    异常处理代码
}
...
catch(异常类型) {
    异常处理代码
}

catch 可以有多个，但至少要有一个。
不妨把 try 和其后中的内容称作“try块”，把 catch 和其后中的内容称作“catch块”。

• 执行 try 块中的语句，如果执行的过程中没有异常拋出，那么执行完后就执行最后一个 catch 块后面的语句，所有 catch 块中的语句都不会被执行；
• 如果 try 块执行的过程中拋出了异常，那么拋出异常后立即跳转到第一个“异常类型”和拋出的异常类型匹配的 catch 块中执行（称作异常被该 catch 块“捕获”），执行完后再跳转到最后一个 catch 块后面继续执行。

例如下面的程序：

#include 
using namespace std;
int main()
{
    double m ,n;
    cin >> m >> n;
    try {
        cout << "before dividing." << endl;
        if( n == 0)
            throw -1; //抛出int类型异常
        else
            cout << m / n << endl;
        cout << "after dividing." << endl;
    }
    catch(double d) {
        cout << "catch(double) " << d <<  endl;
    }
    catch(int e) {
        cout << "catch(int) " << e << endl;
    }
    cout << "finished" << endl;
    return 0;
}

程序的运行结果如下：

9 6↙
before dividing.
1.5
after dividing.
finished

说明当 n 不为 0 时，try 块中不会拋出异常。因此程序在 try 块正常执行完后，越过所有的 catch 块继续执行，catch 块一个也不会执行。

程序的运行结果也可能如下：

9 0↙
before dividing.
catch\(int) -1
finished

当 n 为 0 时，try 块中会拋出一个整型异常。拋出异常后，try 块立即停止执行。该整型异常会被类型匹配的第一个 catch 块捕获，即进入`catch(int e)`块执行，该 catch 块执行完毕后，程序继续往后执行，直到正常结束。

如果拋出的异常没有被 catch 块捕获，例如，将catch(int e)，改为catch(char e)，当输入的 n 为 0 时，拋出的整型异常就没有 catch 块能捕获，这个异常也就得不到处理，那么程序就会立即中止，try…catch 后面的内容都不会被执行。

能够捕获任何异常的catch语法

如果希望不论拋出哪种类型的异常都能捕获，可以编写如下 catch 块：

catch(...) {
    ...
}

这样的 catch 块能够捕获任何还没有被捕获的异常。例如下面的程序：

#include 
using namespace std;
int main()
{
    double m, n;
    cin >> m >> n;
    try {
        cout << "before dividing." << endl;
        if (n == 0)
            throw - 1;  //抛出整型异常
        else if (m == 0)
            throw - 1.0;  //拋出 double 型异常
        else
            cout << m / n << endl;
        cout << "after dividing." << endl;
    }
    catch (double d) {
        cout << "catch (double)" << d << endl;
    }
    catch (...) {
        cout << "catch (...)" << endl;
    }
    cout << "finished" << endl;
    return 0;
}

程序的运行结果如下：

9 0↙
before dividing.
catch (...)
finished
当 n 为 0 时，拋出的整型异常被`catchy(...)`捕获。

程序的运行结果也可能如下：

0 6↙
before dividing.
catch (double) -1
finished

当 m 为 0 时，拋出一个 double 类型的异常。虽然`catch (double)`和`catch(...)`都能匹配该异常，但是`catch(double)`是第一个能匹配的 catch 块，因此会执行它，而不会执行`catch(...)`块。

由于`catch(...)`能匹配任何类型的异常，它后面的 catch 块实际上就不起作用，因此不要将它写在其他 catch 块前面。 

异常的再抛出

如果一个函数在执行过程中拋出的异常在本函数内就被 catch 块捕获并处理，那么该异常就不会拋给这个函数的调用者（也称为“上一层的函数”）；如果异常在本函数中没有被处理，则它就会被拋给上一层的函数。例如下面的程序：

#include 
#include 
using namespace std;
class CException
{
public:
    string msg;
    CException(string s) : msg(s) {}
};
double Devide(double x, double y)
{
    if (y == 0)
        throw CException("devided by zero");
    cout << "in Devide" << endl; //14
    return x / y;
}
int CountTax(int salary)
{
    try {
        if (salary < 0)
            throw - 1;
        cout << "counting tax" << endl;
    }
    catch (int) {
        cout << "salary < 0" << endl;
    }
    cout << "tax counted" << endl;
    return salary * 0.15;
}
int main()
{
    double f = 1.2;
    try {
        CountTax(-1);
        f = Devide(3, 0);     //35
        cout << "end of try block" << endl;
    }
    catch (CException e) {
        cout << e.msg << endl;
    }
    cout << "f = " << f << endl;
    cout << "finished" << endl;
    return 0;
}

程序的输出结果如下：

salary < 0
tax counted
devided by zero
f=1.2
finished

CountTa 函数拋出异常后自行处理，这个异常就不会继续被拋给调用者，即 main 函数。因此在 main 函数的 try 块中，CountTax 之后的语句还能正常执行，即会执行`f = Devide(3, 0);`。

第 35 行，Devide 函数拋出了异常却不处理，该异常就会被拋给 Devide 函数的调用者，即 main 函数。拋出此异常后，Devide 函数立即结束，第 14 行不会被执行，函数也不会返回一个值，这从第 35 行 f 的值不会被修改可以看出。

Devide 函数中拋出的异常被 main 函数中类型匹配的 catch 块捕获。第 38 行中的 e 对象是用复制构造函数初始化的。

如果拋出的异常是派生类的对象，而 catch 块的异常类型是基类，那么这两者也能够匹配，因为派生类对象也是基类对象。

虽然函数也可以通过返回值或者传引用的参数通知调用者发生了异常，但采用这种方式的话，每次调用函数时都要判断是否发生了异常，这在函数被多处调用时比较麻烦。有了异常处理机制，可以将多处函数调用都写在一个 try 块中，任何一处调用发生异常都会被匹配的 catch 块捕获并处理，也就不需要每次调用后都判断是否发生了异常。

有时，虽然在函数中对异常进行了处理，但是还是希望能够通知调用者，以便让调用者知道发生了异常，从而可以作进一步的处理。在 catch 块中拋出异常可以满足这种需要。例如：

#include 
#include 
using namespace std;
int CountTax(int salary)
{
    try {
        if( salary < 0 )
            throw string("zero salary");
        cout << "counting tax" << endl;

    }
    catch (string s ) {
        cout << "CountTax error : " << s << endl;
        throw; //继续抛出捕获的异常  14
    }
    cout << "tax counted" << endl;
    return salary * 0.15;
}
int main()
{
    double f = 1.2;
    try {
        CountTax(-1);
        cout << "end of try block" << endl;
    }
    catch(string s) {
        cout << s << endl;
    }
    cout << "finished" << endl;
    return 0;
}

程序的输出结果如下：
CountTax error:zero salary
zero salary
finished

第 14 行的throw;没有指明拋出什么样的异常，因此拋出的就是 catch 块捕获到的异常，即 string(“zero salary”)。这个异常会被 main 函数中的 catch 块捕获。

函数的异常声明列表

为了增强程序的可读性和可维护性，使程序员在使用一个函数时就能看出这个函数可能会拋出哪些异常，C++ 允许在函数声明和定义时，加上它所能拋出的异常的列表，具体写法如下：

void func() throw (int, double, A, B, C);

或

void func() throw (int, double, A, B, C){...}

上面的写法表明 func 可能拋出 int 型、double 型以及 A、B、C 三种类型的异常。异常声明列表可以在函数声明时写，也可以在函数定义时写。如果两处都写，则两处应一致。

如果异常声明列表如下编写：

void func() throw ();

则说明 func 函数不会拋出任何异常。

一个函数如果不交待能拋出哪些类型的异常，就可以拋出任何类型的异常。

函数如果拋出了其异常声明列表中没有的异常，在编译时不会引发错误，但在运行时， Dev C++ 编译出来的程序会出错；用 Visual Studio编译出来的程序则不会出错，异常声明列表不起实际作用。

C++标准异常类

C++ 标准库中有一些类代表异常，这些类都是从 exception 类派生而来的。常用的几个异常类如图所示。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-eMpXIuQ2-1612432979680)(\resource\异常类.jpg)]

bad_typeid、bad_cast、bad_alloc、ios_base::failure、out_of_range 都是 exception 类的派生类。C++ 程序在碰到某些异常时，即使程序中没有写 throw 语句，也会自动拋出上述异常类的对象。这些异常类还都有名为 what 的成员函数，返回字符串形式的异常描述信息。使用这些异常类需要包含头文件 stdexcept。

下表是对上面层次结构中出现的每个异常的说明：

异常描述

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-UlWsu0sa-1612432979683)(\resource\异常类表.jpg)]

1) bad_typeid

使用 typeid 运算符时，如果其操作数是一个多态类的指针, 而该指针的值为 NULL，则会拋出此异常。

2) bad_cast

在用 dynamic_cast 进行从多态基类对象（或引用）到派生类的引用的强制类型转换时，如果转换是不安全的，则会拋出此异常。程序示例如下：

#include 
#include 
using namespace std;
class Base
{
    virtual void func() {}
};
class Derived : public Base
{
public:
    void Print() {}
};
void PrintObj(Base & b)
{
    try {
        Derived & rd = dynamic_cast (b);
        //此转换若不安全，会拋出 bad_cast 异常
        rd.Print();
    }
    catch (bad_cast & e) {
        cerr << e.what() << endl;
    }
}
int main()
{
    Base b;
    PrintObj(b);
    return 0;
}

程序的输出结果如下：
Bad dynamic_cast!

在 PrintObj 函数中，通过 dynamic_cast 检测 b 是否引用的是一个 Derived 对象，如果是，就调用其 Print 成员函数；如果不是，就拋出异常，不会调用 Derived::Print。

3) bad_alloc

在用 new 运算符进行动态内存分配时，如果没有足够的内存，则会引发此异常。程序示例如下：

#include 
#include 
using namespace std;
int main()
{
    try {
        char * p = new char[0x7fffffff];  //无法分配这么多空间，会抛出异常
    }
    catch (bad_alloc & e)  {
        cerr << e.what() << endl;
    }
    return 0;
}

程序的输出结果如下：
bad allocation
ios_base::failure

在默认状态下，输入输出流对象不会拋出此异常。如果用流对象的 exceptions 成员函数设置了一些标志位，则在出现打开文件出错、读到输入流的文件尾等情况时会拋出此异常。此处不再赘述。

4) out_of_range

用 vector 或 string 的 at 成员函数根据下标访问元素时，如果下标越界，则会拋出此异常。例如：

#include 
#include 
#include 
#include 
using namespace std;
int main()
{
    vector v(10);
    try {
        v.at(100) = 100;  //拋出 out_of_range 异常
    }
    catch (out_of_range & e) {
        cerr << e.what() << endl;
    }
    string s = "hello";
    try {
        char c = s.at(100);  //拋出 out_of_range 异常
    }
    catch (out_of_range & e) {
        cerr << e.what() << endl;
    }
    return 0;
}

程序的输出结果如下：
invalid vector subscript
invalid string position

如果将v.at(100)换成v[100]，将s.at(100)换成s[100]，程序就不会引发异常（但可能导致程序崩溃）。因为 at 成员函数会检测下标越界并拋出异常，而 operator[] 则不会。operator [] 相比 at 的好处就是不用判断下标是否越界，因此执行速度更快。

参考文档：http://c.biancheng.net/view/422.html

参考文档：https://blog.csdn.net/qq_21743659/article/details/109175625

参考文档：https://zhuanlan.zhihu.com/p/270252347?utm_source=com.vrv.im&utm_medium=social&utm_oi=605515163114409984

机制详解

编译器如何实现函数的调用和返回。一般来说，编译器会为当前调用栈里的每个函数建立一个栈框架（Stack Frame）。“栈框架”担负着以下重要任务：

1. 传递参数：通常，函数的调用参数总是在这个函数栈框架的最顶端。
2. 传递返回地址：告诉被调用者的 return 语句应该 return 到哪里去，通常指向该函数调用的下一条语句（代码段中的偏移）。
3. 存放调用者的当前栈指针：便于清理被调用者的所有局部变量、并恢复调用者的现场。
4. 存放当前函数内的所有局部变量：所有局部和临时变量都是存储在栈上的。

栈是一种“后进先出”（LIFO）的数据结构，不过实际上大部分栈的实现都支持随机访问。

下面我们来看个具体例子：

假设有 FuncA、FuncB 和 FuncC 三个函数，每个函数均接收两个整形值作为其参数。在某线程上的某一时间段内，FuncA 调用了 FuncB，而 FuncB 又调用了 FuncC。则，它们的栈框架看起来应该像这样：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-17lECiYj-1612432979685)(\resource\函数栈框架.png)]

																图1 函数调用栈框架示例 

​ 正如上图所示的那样，随着函数被逐级调用，编译器会为每一个函数建立自己的栈框架，栈空间逐渐消耗。随着函数的逐级返回，该函数的栈框架也将被逐级销毁，栈空间得以逐步释放。顺便说一句，递归函数的嵌套调用深度通常也是取决于运行时栈空间的剩余尺寸。

这里顺便解释另一个术语：调用约定（calling convention）。调用约定通常指：调用者将参数压入栈中（或放入寄存器中）的顺序，以及返回时由谁（调用者还是被调用者）来清理这些参数等细节规程方面的约定。

最后再说一句，这里所展示的函数调用乃是最“经典”的方式。实际情况是：在开启了优化选项后，编译器可能不会为一个内联甚至非内联的函数生成栈框架，编译器可能使用很多优化技术消除这个构造。不过对于一个 C/C++ 程序员来说，达到这样的理解程度通常就足够了。

C++函数的调用和返回

首先澄清一点，这里说的 “C++ 函数”是指：

1. 该函数可能会直接或间接地抛出一个异常：即该函数的定义存放在一个 C++ 编译（而不是传统 C）单元内，并且该函数没有使用“throw()”异常过滤器。
2. 或者该函数的定义内使用了 try 块。

以上两者满足其一即可。为了能够成功地捕获异常和正确地完成栈回退（stack unwind），编译器必须要引入一些额外的数据结构和相应的处理机制。我们首先来看看引入了异常处理机制的栈框架大概是什么样子：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-uFRrfPDw-1612432979687)(\resource\C++函数调用栈.png)]

																图2 C++函数调用栈框架示例 

由图2可见，在每个 C++ 函数的栈框架中都多了一些东西。仔细观察的话，你会发现，多出来的东西正好是一个 EXP 类型的结构体。进一步分析就会发现，这是一个典型的单向链表式结构：

• piPrev 成员指向链表的上一个节点，它主要用于在函数调用栈中逐级向上寻找匹配的 catch 块，并完成栈回退工作。
• piHandler 成员指向完成异常捕获和栈回退所必须的数据结构（主要是两张记载着关键数据的表：“try”块表：tblTryBlocks 及“栈回退表”：tblUnwind）。
• nStep 成员用来定位 try 块，以及在栈回退表中寻找正确的入口。

需要说明的是：编译器会为每一个“C++ 函数”定义一个 EHDL结构，不过只会为包含了“try”块的函数定义 tblTryBlocks成员。此外，异常处理器还会为每个线程维护一个指向当前异常处理框架的指针。该指针指向异常处理器链表的链尾，通常存放在某个 TLS 槽或能起到类似作用的地方。

最后，请再看一遍图2，并至少对其中的数据结构留下一个大体印象。我们会在后面多个小节中详细讨论它们。

注意：为了简化起见，本文中描述的数据结构内，大多省略了一些与话题无关的成员。

栈回退（Stack Unwind）机制

“栈回退”是伴随异常处理机制引入 C++ 中的一个新概念，主要用来确保在异常被抛出、捕获并处理后，所有生命期已结束的对象都会被正确地析构，它们所占用的空间会被正确地回收。

受益于栈回退机制的引入，以及 C++ 类所支持的“资源申请即初始化”语意，使得我们终于能够彻底告别既不优雅也不安全的 setjmp/longjmp 调用，简便又安全地实现远程跳转了。我想这也是 C++ 异常处理机制在错误处理以外唯一一种合理的应用方式了。

下面我们就来具体看看编译器是如何实现栈回退机制的：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-6Qzyo8YH-1612432979688)(\resource\栈回退.png)]

​ 图3 C++ 栈回退机制

图3中的“FuncUnWind”函数内，所有真实代码均以黑色和蓝色字体标示，编译器生成的代码则由灰色和橙色字体标明。此时，在图2里给出的 nStep 变量和 tblUnwind 成员作用就十分明显了。

nStep 变量用于跟踪函数内局部对象的构造、析构阶段。再配合编译器为每个函数生成的 tblUnwind 表，就可以完成退栈机制。表中的 pfnDestroyer 字段记录了对应阶段应当执行的析构操作（析构函数指针）；pObj 字段则记录了与之相对应的对象 this 指针偏移。将 pObj 所指的偏移值加上当前栈框架基址（EBP），就是要代入 pfnDestroyer 所指析构函数的 this 指针，这样即可完成对该对象的析构工作。而 nNextIdx 字段则指向下一个需要析构对象所在的行（下标）。

在发生异常时，异常处理器首先检查当前函数栈框架内的 nStep 值，并通过 piHandler 取得 tblUnwind[] 表。然后将 nStep 作为下标带入表中，执行该行定义的析构操作，然后转向由 nNextIdx 指向的下一行，直到 nNextIdx 为 -1 为止。在当前函数的栈回退工作结束后，异常处理器可沿当前函数栈框架内 piPrev 的值回溯到异常处理链中的上一节点重复上述操作，直到所有回退工作完成为止。

值得一提的是，nStep 的值完全在编译时决定，运行时仅需执行若干次简单的整形立即数赋值（通常是直接赋值给CPU里的某个寄存器）。此外，对于所有内部类型以及使用了默认构造、析构方法（并且它的所有成员和基类也使用了默认方法）的类型，其创建和销毁均不影响 nStep 的值。

注意：如果在栈回退的过程中，由于析构函数的调用而再次引发了异常（异常中的异常），则被认为是一次异常处理机制的严重失败。此时进程将被强行禁止。为防止出现这种情况，应在所有可能抛出异常的析构函数中使用“std::uncaught_exception()”方法判断当前是否正在进行栈回退（即：存在一个未捕获或未完全处理完毕的异常）。如是，则应抑制异常的再次抛出。

异常捕获机制

一个异常被抛出时，就会立即引发 C++ 的异常捕获机制：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-KhKCA9aS-1612432979691)(\resource\异常捕获机制.png)]

​ 图4 C++ 异常捕获机制

在上一小节中，我们已经看到了 nStep 变量在跟踪对象构造、析构方面的作用。实际上 nStep 除了能够跟踪对象创建、销毁阶段以外，还能够标识当前执行点是否在 try 块中，以及（如果当前函数有多个 try 块的话）究竟在哪个 try 块中。这是通过在每一个 try 块的入口和出口各为 nStep 赋予一个唯一 ID 值，并确保 nStep 在对应 try 块内的变化恰在此范围之内来实现的。

在具体实现异常捕获时，首先，C++ 异常处理器检查发生异常的位置是否在当前函数的某个 try 块之内。这项工作可以通过将当前函数的 nStep 值依次在 piHandler 指向 tblTryBlocks[] 表的条目中进行范围为 [nBeginStep, nEndStep) 的比对来完成。

例如：若图4 中的 FuncB 在 nStep == 2 时发生了异常，则通过比对 FuncB 的 tblTryBlocks[] 表发现 2∈[1, 3)，故该异常发生在 FuncB 内的第一个 try 块中。

其次，如果异常发生的位置在当前函数中的某个 try 块内，则尝试匹配该 tblTryBlocks[] 相应条目中的 tblCatchBlocks[] 表。tblCatchBlocks[] 表中记录了与指定 try 块配套出现的所有 catch 块相关信息，包括这个 catch 块所能捕获的异常类型及其起始地址等信息。

若找到了一个匹配的 catch 块，则复制当前异常对象到此 catch 块，然后跳转到其入口地址执行块内代码。

否则，则说明异常发生位置不在当前函数的 try 块内，或者这个 try 块中没有与当前异常相匹配的 catch 块，此时则沿着函数栈框架中 piPrev 所指地址（即：异常处理链中的上一个节点）逐级重复以上过程，直至找到一个匹配的 catch 块或到达异常处理链的首节点。对于后者，我们称为发生了未捕获的异常，对于 C++ 异常处理器而言，未捕获的异常是一个严重错误，将导致当前进程被强制结束。

注意：虽然在图4示例中的 tblTryBlocks[] 只有一个条目，这个条目中的 tblCatchBlocks[] 也只有一行。但是在实际情况中，这两个表中都允许有多条记录。意即：一个函数中可以有多个 try 块，每个 try 块后均可跟随多个与之配套的 catch 块。

注意：按照标准意义上的理解，异常时的栈回退是伴随着异常捕获过程沿着异常处理链逐层向上进行的。但是有些编译器是在先完成异常捕获后再一次性进行栈回退的。无论具体实现使用了哪种方式，除非正在开发一个内存严格受限的嵌入式应用，通常我们按照标准语意来理解都不会产生什么问题。

备注：实际上 tblCatchBlocks 中还有一些较为关键但被故意省略的字段。比如指明该 catch 块异常对象复制方式（传值（拷贝构造）或传址（引用或指针））的字段，以及在何处存放被复制的异常对象（相对于入口地址的偏移位置）等信息。

异常的抛出

接下来讨论整个 C++ 异常处理机制中的最后一个环节，异常的抛出：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-2Z9dVyeu-1612432979692)(\resource\异常抛出.png)]

																图5 C++ 异常抛出 

在编译一段 C++ 代码时，编译器会将所有 throw 语句替换为其 C++ 运行时库中的某一指定函数，这里我们叫它 __CxxRTThrowExp（与本文提到的所有其它数据结构和属性名一样，在实际应用中它可以是任意名称）。该函数接收一个编译器认可的内部结构（我们叫它 EXCEPTION 结构）。这个结构中包含了待抛出异常对象的起始地址、用于销毁它的析构函数，以及它的 type_info 信息。对于没有启用 RTTI 机制（编译器禁用了 RTTI 机制或没有在类层次结构中使用虚表）的异常类层次结构，可能还要包含其所有基类的 type_info 信息，以便与相应的 catch 块进行匹配。

在图5中的深灰色框图内，我们使用 C++ 伪代码展示了函数 FuncA 中的 “throw myExp(1);” 语句将被编译器最终翻译成的样子。实际上在多数情况下，__CxxRTThrowExp 函数即我们前面曾多次提到的“异常处理器”，异常捕获和栈回退等各项重要工作都由它来完成。

__CxxRTThrowExp 首先接收（并保存）EXCEPTION 对象；然后从 TLS：Current ExpHdl 处找到与当前函数对应的 piHandler、nStep 等异常处理相关数据；并按照前文所述的机制完成异常捕获和栈回退。由此完成了包括“抛出”->“捕获”->“回退”等步骤的整套异常处理机制。

异常处理机制的开销分析

至此，我们已完整地阐述了整套 C++ 异常处理机制的实现原理。我在本文的开头曾提到，作为一名 C++ 程序员，了解其某一特性的实现原理主要是为了避免错误地使用该特性。要达到这个目的，还要在了解实现原理的基础上进行一些额外的开销分析工作：

特性	时间开销	空间开销
EHDL	无运行时开销	每“C++函数”一个 EHDL 对象，其中的 tblTryBlocks[] 成员仅在函数中包含至少一个 try 块时使用。典型情况下小于 64 字节。
C++栈框架	极高的 O(1) 效率，每次调用时进行3次额外的整形赋值和一次 TLS 访问。	每 调用两个指针和一个整形开销。典型情况下小于 16 字节。
step 跟踪	极高的 O(1) 效率每次进出 try 块或对象构造/析构一次整形立即数赋值。	无（已记入 C++ 栈框架中的相应项目）。
异常的抛出、捕获和栈回退	异常的抛出是一次 O(1) 级操作。在单个函数中进行捕获和栈回退也均为 O(1) 操作。但异常捕获的总体成本为 O(m)，其中 m 等于当前函数调用栈中，从抛出异常的位置到达匹配 catch 块之间所经过的函数调用中，包含 try 块（即：定义了有效 tblTryBlocks[]）的函数个数。栈回退的总成本为 O(n)，其中 n 等于当前函数调用栈中，从抛出异常的位置到达匹配 catch 块之间所经过的函数调用数。	在异常处理结束前，需保存异常对象及其析构函数指针和相应的 type_info 信息。具体根据对象尺寸、编译器选项（是否开启 RTTI）及异常捕获器的参数传递方式（传值或传址）等因素有较大变化。典型情况下小于 256 字节。

可以看出，在没有抛出异常时，C++ 的异常处理机制是十分有效的。在有异常被抛出后，可能会依当前函数调用栈的情形进行若干次整形比较（try块表匹配）操作，但这通常不会超过几十次。对于大多数 15 年前的 CPU 来说，整形比较也只需 1 时钟周期，所以异常捕获的效率还是很高的。栈回退的效率则与 return 语句基本相当。

考虑到即使是传统的函数调用、错误处理和逐级返回机制也不是没有代价的。这些开销在绝大多数情形下仍可以接受。空间开销方面，每“C++ 函数”一个 EHDL 结构体的引入在某些极端情形下会明显增加目标文件尺寸和内存开销。但是典型情况下，它们的影响并不大，但也没有小到可以完全忽略的程度。如果正在为一个资源严格受限的环境开发应用程序，你可能需要考虑关闭异常处理和 RTTI 机制以节约存储空间。

以上讨论的是一种典型的异常机制的实现方式，各具体编译器厂商可能有自己的优化和改进方案，但总体的出入不会很大。

总结

1. 使用异常处理的优点：

传统错误处理技术，检查到一个错误，只会返回退出码或者终止程序等等，我们只知道有错误，但不能更清楚知道是哪种错误。使用异常，把错误和处理分开来，由库函数抛出异常，由调用者捕获这个异常，调用者就可以知道程序函数库调用出现的错误是什么错误，并去处理，而是否终止程序就把握在调用者手里了。

2. 使用异常的缺点：

如果使用异常，光凭查看代码是很难评估程序的控制流：函数返回点可能在你意料之外，这就导致了代码管理和调试的困难。启动异常使得生成的二进制文件体积变大，延长了编译时间，还可能会增加地址空间的压力。

C++没有垃圾回收机制，资源需要自己管理。有了异常非常容易导致内存泄漏、死锁等异常安全问题。 这个需要使用RAII来处理资源的管理问题。学习成本较高。

C++标准库的异常体系定义得不好，导致大家各自定义各自的异常体系，非常的混乱。

3. 什么时候使用异常？

建议：除非已有的项目或底层库中使用了异常，要不然尽量不要使用异常，虽然提供了方便，但是开销也大。

4. 程序所有的异常都可以catch到吗？

并非如此，只有发生异常，并且又抛出异常的情况才能被 catch 到。例如，数组下标访问越界的情况，系统是不会自身抛出异常的，所以我们无论怎么 catch 都是无效的；在这种情况，我们需要自定义抛出类型，判断数组下标是否越界，然后再根据自身需要throw自定义异常对象，这样才可以catch到异常，并进行进一步处理。

​ 异常处理是 C++ 中十分有用的崭新特性之一。在绝大多数情况下，它们都有着优异的表现和令人满意的时空效率。异常处理本质上是另一种返回机制。但无论从软件工程、模块设计、编码习惯还是时空效率等角度来说，除了在有充分文档说明的前提下，偶尔可用来替代替代传统的 setjmp/longjmp 功能外，应保证只将其用于程序的错误处理机制中。此外，由于长跳转的使用既易于出错，又难于理解和维护。在编码过程中也应当尽量避免使用。

参考文档：https://www.cnblogs.com/tgycoder/p/5427303.html

参考文档：https://blog.csdn.net/pzp201833/article/details/80996133

参考文档： http://www.baiy.cn/doc/cpp/inside_exception.htm

4. 程序所有的异常都可以catch到吗？

并非如此，只有发生异常，并且又抛出异常的情况才能被 catch 到。例如，数组下标访问越界的情况，系统是不会自身抛出异常的，所以我们无论怎么 catch 都是无效的；在这种情况，我们需要自定义抛出类型，判断数组下标是否越界，然后再根据自身需要throw自定义异常对象，这样才可以catch到异常，并进行进一步处理。

​ 异常处理是 C++ 中十分有用的崭新特性之一。在绝大多数情况下，它们都有着优异的表现和令人满意的时空效率。异常处理本质上是另一种返回机制。但无论从软件工程、模块设计、编码习惯还是时空效率等角度来说，除了在有充分文档说明的前提下，偶尔可用来替代替代传统的 setjmp/longjmp 功能外，应保证只将其用于程序的错误处理机制中。此外，由于长跳转的使用既易于出错，又难于理解和维护。在编码过程中也应当尽量避免使用。

参考文档：https://www.cnblogs.com/tgycoder/p/5427303.html

参考文档：https://blog.csdn.net/pzp201833/article/details/80996133

参考文档： http://www.baiy.cn/doc/cpp/inside_exception.htm