C++异常机制解析

传统排错

我们早在 C 程序里面传统的错误处理手段有：

1. 终止程序，如 assert；缺陷是用户难以接受，说白了就是一种及其粗暴的手法，比如发生内存错误，除0错误时就会终止程序。
2. 返回错误码。缺陷是需要我们自己去查找错误，如系统的很多库的接口函数都是通过把错误码放到 errno 中，表示错误。
3. C标准库中 setjmp 和 longjmp 组合（不常用）

实际中 C 语言基本都是使用返回错误码的方式处理错误，部分情况下使用终止程序处理非常严重紧急的错误，因此异常机制就时运而横空出世

概念

异常是面向对象语言常用的一种处理错误的方式，当一个函数发现自己无法处理的错误时就可以抛出异常，让函数直接或间接调用者自己来处理这个错误

1. throw：当程序出现问题时，可以通过 throw 关键字抛出一个异常
2. try：try 块中放置的是可能抛出异常的代码，该代码块在执行时将进行异常错误检测，try 块后面通常跟着一个或多个 catch 块。
3. catch：如果try块中发生错误，则可以在 catch 块中定义对应要执行的代码块。

try-catch 语句的语法实例：

用法

异常是通过抛出对象而引发的，该对象的类型决定了应该激活哪个 catch 的处理代码，如果抛出的异常对象没有捕获，或是没有匹配类型的捕获，那么程序会终止报错

异常捕获和抛出

被选中的处理代码（catch块）是调用链中与该对象类型匹配且离抛出异常位置最近的那一个

抛出异常对象后，会生成一个异常对象的拷贝，因为抛出的异常对象可能是一个临时对象，所以会生成一个拷贝对象 color{red} {因为抛出的异常对象可能是一个临时对象，所以会生成一个拷贝对象}因为抛出的异常对象可能是一个临时对象，所以会生成一个拷贝对象，这个拷贝的临时对象会在被 catch 以后销毁（类似于函数的传值返回）

catch(…) 可以捕获任意类型的异常，但捕获后无法知道异常错误是什么，实际异常抛出和捕获的匹配原则有个例外，捕获和抛出的异常类型并不一定要完全匹配，可以抛出派生类对象，使用基类进行捕获，这个在实际中非常有用

在函数调用链中异常栈展开的匹配原则：

当异常被抛出后，首先检查 throw 本身是否在 try 块内部，如果在则查找匹配的 catch 语句，如果有匹配的就跳到 catch 的地方进行处理

如果当前没有匹配的 catch 则退出当前函数栈，继续在上一个调用中进行查找 catch。找到匹配的 catch 子句并处理以后，会沿着 catch 子句后面继续执行，而不会跳回到原来抛异常的地方，如果到达 main 函数的栈，依旧没有找到匹配的 catch 则终止程序

比如下面的代码中调用了 func3，func3 中调用 func2，func2 中调用 func1，func1 中抛出了一个 string 的异常对象：

首先会检查 throw 本身是否在 try 块内部，这里就会因此退出 func1 所在的函数栈，继续在上一个调用栈中进行查找，即 func2 所在的函数栈，由于 func2 中也没有匹配的 catch，因此会继续复读套娃，最终在 main 函数栈中找到匹配的 catch

这时就会跳到 main 函数中对应的 catch 块中执行对应的代码块，执行完后继续执行该代码块后续的代码：

当然为了防止还有漏网之鱼，一般此时我们还会搞一个 catch(…) 进行全捕获。

异常的重新抛出

要知道一个 catch 是无法完全搞定异常的，如果我们对异常进行修正后，希望交付给上层调用链进行异常的异常信息日志记录，此时就需要我们重新对上层函数抛异常：

这里 func2 最后应该 delete 进行空间释放，但由于 func2 中途调用 func1 ，func1 内部抛出了一个异常，这时会直接跳转到 main 函数中的 catch 块执行对应的异常处理程序，并且在处理完后继续沿着 catch 块往后执行，这时就导致 func2 中内存块没有得到释放，造成了内存泄露！

此时我们应该在 func2 中先对 func1 抛出的异常进行捕获，捕获后先将内存释放再重新抛出异常，就可以避免内存泄露：

try-catch 中 new 和 delete 之间可能还会抛出其他类型的异常，因此在 fun2 中最好再进行 catch(…) ，将申请到的内存 delete 后再通过throw 重新抛出；重新抛出异常对象时，此时 throw 可以不用指明要抛出的异常对象，其实 catch(…) 也不知道自己到底捕了个什么异常对象

安全第一条

还是那句话，道路千万条，抛异常要谨慎：

1. 构造函数完成对象的构造和初始化，最好不要在构造函数中抛出异常，否则可能导致对象不完整或没有完全初始化
2. 析构函数完成对象资源的清理，最好不要在析构函数中抛出异常，否则可能导致内存泄露，句柄未关闭等
3. C++ 中在 new 和 delete 中抛出异常经常是内存泄漏的罪魁祸首，在 lock 和 unlock 之间抛出异常导致死锁，C++ 经常使用 RAII 的方式来解决类似问题

规范使用

站在异常的严谨立场上， C++ 也在尽量提高咱的使用规范：

在函数的后面接throw(type1, type2, …)，列出这个函数可能抛掷的所有异常类型
在函数的后面接throw()或noexcept（C++11），表示该函数不抛异常
若无异常接口声明，则此函数可以抛掷任何类型的异常（异常接口声明不是强制的）

异常体系

因为异常属实需要严谨与规范的操作，所以在很多公司里面都会制定自己的一套异常的规范管理：

公司中的项目一般会进行模块划分，让不同的人或小组完成不同的模块，如果不对抛异常这件事进行规范，那么在最外层捕获异常的冤种就会问候亲妈了，因为他会来给各位擦屁股，捕获大家抛出的所以异常对象 color{red} {那么在最外层捕获异常的冤种就会问候亲妈了，因为他会来给各位擦屁股，捕获大家抛出的所以异常对象}那么在最外层捕获异常的冤种就会问候亲妈了，因为他会来给各位擦屁股，捕获大家抛出的所以异常对象

我们之前说过异常语法可以用基类捕获抛出的派生类对象，因此实际中都会先定义一个最基础的异常类，所有人抛出的异常对象都必须是继承于该异常类的派生类对象，，因此最外层就只需捕获基类就行了

最基础的异常类至少需要包含错误编号和错误描述两个成员变量，甚至还可以包含当前函数栈帧的调用链等信息，该异常类中一般还会提供两个成员函数，分别用来获取错误编号和错误描述

其他人如果要对这个异常类进行扩展，必须先继承基础异常类，然后按需添加某些成员变量，或是对虚函数what 进行重写，使其能告知更多的异常信息：

异常类的成员变量不能设置为私有，因为私有成员在子类中是不可见的。基类 Exception 中 what 成员函数最好定义为虚函数，方便子类对其进行重写，从而达到多态的效果

标准库体系

C++ 标准库当中的异常也是一个基础体系，其中 exception 就是基类，它与其他异常类的继承关系如下：

其中具体信息如下：

我们可以去继承这里的 exception 类来实现自己的异常类，但实际上很多公司都会自己定义一套异常继承体系！

优缺点

目前情况来看，异常是利大于弊的，还是鼓励使用异常的，而且前排的语言基本都会使用异常处理错误，这也可以看出这是大势所趋

异常的优点：

相比错误码，异常可以清晰准确的展示出错误的各种信息，甚至可以包含堆栈调用等信息，这样可以帮助更好的定位程序的bug

返回错误码的传统方式有个很大的问题就是，在函数调用链中，深层的函数返回了错误，那么我们得层层返回错误码，最终最外层才能拿到错误

很多的第三方库都会使用异常，比如 boost、gtest、gmock 等常用的库，如果我们不用异常就不能很好的发挥这些库的作用，很多测试框架也都使用异常，因此使用异常能更好的使用单元测试等进行白盒测试

部分函数使用异常更好处理，比如 T& operator 这样的函数，如果 pos 越界了只能使用异常或者终止程序处理，没办法通过返回值表示错误

异常的缺点：

异常会导致程序的执行流混乱，这会导致我们跟踪调试或分析程序时比较困难。异常还会有一些性能的开销，当然在现代硬件速度很快的情况下，这个影响基本忽略不计！

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

C++ 标准库的异常体系定义得不够好，导致大家各自定义自己的异常体系，非常的混乱，异常尽量规范使用，否则后果不堪设想，随意抛异常，也会让外层捕获的用户苦不堪言。

异常接口声明不是强制的，对于没有声明异常类型的函数，无法预知该函数是否会抛出异常