一. 异常机制的引入在 C 语言时代错误处理是一项繁琐的工作你必须小心翼翼地检查每一个函数的返回值。如果一个函数在调用链的第 10 层报错那么中间的 9 层函数都需要复读写 if (err ! 0) return err。这种做法不仅让业务逻辑被错误处理淹没更致命的是开发者极易忽略错误检查异常的设计初衷就是为了实现逻辑隔离与强制处理遵循正常逻辑的流畅执行流程同时将错误处理独立封装在 catch 块中。若未捕获异常程序将立即终止运行。异常不再是可被忽略的返回值而是必须直面处理的问题。异常机制能够跨越函数层级将错误信息从底层直接传递到具备处理能力的高层模块二. 异常的使用1. 异常的基本语法异常处理的核心由三个关键字组成throw当程序发现无法处理的问题时通过该关键字抛出一个异常对象try标识一段可能触发异常的代码块catch紧跟在 try 块之后用于捕获特定类型的异常并进行处理#include stdexcept // 包含标准异常类 double divide(double a, double b) { if (b 0) { // 1. 抛出异常可以是任何类型但推荐使用标准异常类 throw std::runtime_error(除数不能为零); } return a / b; } void test() { try { // 2. 尝试执行可能出错逻辑 double result divide(10, 0); std::cout 结果: result std::endl; } catch (const std::runtime_error e) { // 3. 捕获并处理, 按类型匹配推荐使用常引用捕获 std::cerr 捕获到异常: e.what() std::endl; } }一个 try 块可以对应多个 catch 块编译器会按照从上到下的顺序进行匹配异常遵循就近匹配原则编译器会从异常抛出点开始由内向外逐层查找匹配的 catch 块。只有当异常对象的类型与 catch块声明的类型兼容时才会被捕获。找到第一个匹配的 catch 块后异常即停止匹配try { // 可能抛出多种异常的代码 } catch (const std::out_of_range e) { // 处理越界异常 } catch (const std::exception e) { // 处理所有继承自 std::exception 的异常 } catch (...) { // 捕获所有类型的异常, 通常用于防止程序崩溃 std::cerr 未知错误 std::endl; }执行 throw 语句会立即终止后续代码的执行控制权将从当前函数跳出沿调用栈向上查找匹配的 catch 块void Func(){ throw exception; // 抛出一个异常 // 在这之后的语句都不会被执行 // cout hello endl; }既然发生了异常说明当前的逻辑已经无法继续维持正确性。强行运行下去只会让错误扩大如操作野指针、写入坏数据。因此最稳妥的处理方法是立刻终止2. 异常对象的存储这是一个非常核心的机制当你抛出一个局部对象时编译器会偷偷做一个拷贝void Func1() { string errMsg 数据库连接失败; throw errMsg; // errMsg 是局部变量函数退出后就销毁了 } void Func2() { try { Func1(); } catch (const string str) { cout str endl; } }因为 Func1 函数在 throw 后会立刻销毁其栈帧为了让后续 Func2 的 catch 块能拿到完整的错误信息编译器会在堆栈之外的一块全局 / 静态区域创建一个 errMsg 的副本这个副本会一直存活直到匹配的 catch 子句执行完毕。它的处理逻辑非常类似于函数的传值返回3. 异常对象与匹配规则值捕获与引用捕获在 catch 子句中你可以像函数传参一样选择值传递或引用传递值捕获Catch by Valuecatch (string s) { // 错误示范值捕获 // ... }双重拷贝我们在第 2 点提到throw 时编译器已经生成了一个异常对象的副本。如果你用值捕获编译器会再次调用拷贝构造函数将副本拷贝给 s。对于大对象这会带来严重的性能开销对象切片这是最致命的问题。如果你抛出一个派生类对象却用基类值捕获派生类特有的成员和虚函数表会被切掉导致多态失效引用捕获Catch by Referencecatch (const string s) { // 推荐做法 // ... }s 直接绑定到异常存储区里的那个副本上没有第二次拷贝并且引用或指针能够识别对象的真实类型确保虚函数调用正确多态异常在实际的大型项目中我们不会为每一种微小的错误都写一个独立的 catch。利用基类捕获派生类的特性我们可以构建层级化的错误处理体系核心机制向上兼容派生类异常对象可以被基类引用捕获虚函数联动通过基类引用调用虚函数可以自动触发派生类的实现从而获取准确的错误描述代码示例// 自定义异常基类 class MyException { public: virtual const char* what() const { return Unknown Exception; } }; // 派生类数据库错误 class SqlException : public MyException { public: virtual const char* what() const { return Database Error!; } }; // 派生类网络错误 class NetException : public MyException { public: virtual const char* what() const { return Network Timeout!; } }; void Test() { if (/*某个逻辑*/) throw SqlException(); if (/*另一个逻辑*/) throw NetException(); } int main() { try { Test(); } // 只需要一个 catch 块就能处理所有从 MyException 继承的异常 catch (const MyException e) { cout 捕获到异常: e.what() endl; } }异常匹配不是最优匹配而最先匹配。这意味着 catch 块的顺序至关重要先写派生类后写基类如果把 catch (MyException e) 放在 catch (SqlException s) 之前try { Test(); } catch (const MyException e) { cout 捕获到异常: e.what() endl; } catch (SqlException s) { // 这里的程序永远不会被运行 }所有的 SqlException 都会被第一个基类块拦截后面的派生类捕获块将永远无法执行4. 栈展开当异常被抛出后程序会开始寻找匹配的 catch 块背后的机制程序会沿着函数调用链倒着往回找。每离开一个作用域编译器都会确保该作用域内所有已经构造好的局部对象被自动析构如果没有栈展开一旦发生异常已经申请的内存、锁定的互斥量、打开的文件句柄就会全部泄露警告千万不要在析构函数里抛出异常如果栈展开过程中又抛出了一个新的异常C 会因为不知道该处理哪一个而直接崩溃5. 异常传播与重新抛出在复杂的工程中错误处理通常是分层的底层如数据库驱动它知道 SQL 报错了但它不知道这个报错对业务意味着什么。它捕获异常是为了记录日志或释放临时资源上层如业务逻辑层它不知道 SQL 的具体错误码但它知道数据库挂了需要给用户弹窗提示这种职责分离的设计理念要求异常在被捕获后能够重新抛出实现错误信息的层级传递1. throwcatch (const MyException e) { // 记录日志... throw; // 原样抛出 }不带任何操作数的 throw;会重新激活当前异常对象的传播它不会创建新拷贝并且保留了多态性。如果你原本抛出的是 SqlException派生类即便在当前 catch 里它是以 MyException基类引用的身份被接住的通过 throw 传递到上层时依然是完整的 SqlException2. throw ecatch (const MyException e) { throw e; // 产生新的抛出 }这相当于发起了一次全新的 throw 操作后果由于 e 是基类类型编译器会根据 MyException 的定义创建一个新的副本。原来派生类特有的成员和虚函数表会被切掉。并且额外增加了一次拷贝构造的开销三. 异常安全与规范1. 异常安全异常的抛出是异步且霸道的。它可能发生在任何一行代码、任何一个构造函数里最典型的灾难性问题内存 / 资源泄露void Func() { int* ptr new int[100]; todo(); // 如果这里抛异常ptr 指向的内存就永远丢了 delete[] ptr; // 永远执行不到 }再比如你在给一个转账系统的 balance 减钱减完了还没来得及给另一个人加钱异常抛出了。此时系统的总金额就不平了这就破坏了数据的完整性解决方案1. 手动清理并抛出这是在没有智能指针时代的做法。你需要在中间层加一个 try-catch在 catch 里手动 delete 资源然后再用 throw把异常传给真正处理逻辑的人void Func() { int* ptr new int[10]; try { todo(); // 如果这里抛异常 } catch (...) { delete[] ptr; // 手动清理 throw; // 重新抛出异常让上层处理业务逻辑 } delete[] ptr; }2. RAII利用RAII我们把资源的生命周期交给了栈上的对象。无论函数怎么退出编译器都会帮我们调用析构函数void Func() { // 使用智能指针管理资源 std::unique_ptrint[] ptr(new int[10]); // 如果这里抛异常栈展开会自动销毁 ptr // ptr 的析构函数会自动调用 delete[] todo(); // 无需手动 delete无需显式 try-catch 清理 }如果异常退出触发栈展开ptr 离开作用域调用析构函数释放内存2. 异常规范与 noexcept在编写大型工程时知道一个函数是否会抛出异常至关重要。如果我调用你的函数而你明确告诉我绝不抛异常那么我的代码逻辑就能极大简化C 在处理异常声明上走过弯路C98 当时允许在函数后写 throw(int, double)表示该函数可能抛出这两种类型的异常或者写 throw() 表示不抛异常这种实现方式增加了编译器的运行时开销需要进行动态检查同时维护成本极高——只要函数内部逻辑发生变动所有相关的调用链声明都必须同步修改C11 删繁就简只剩下两种状态可能抛出和绝不抛出noexcept为函数添加 noexcept 关键字相当于与编译器和调用者签订了一份免责协议void Func() noexcept { // ... }编译器看到 noexcept 后会意识到它不需要为这个函数生成复杂的异常处理表Exception Table从而生成更精简、更高效的可执行代码编译器并不会在编译阶段严密检查你是否真的没抛异常。如果一个声明了 noexcept 的函数在运行期间偷偷抛出了异常程序会直接调用 std::terminate() 暴力终止程序noexcept 的运算符用法它可以在编译期检测一个表达式是否可能抛出异常。用法noexcept(expr) 返回一个布尔值在编写通用模板库时我们需要根据存储的元素类型是否支持 noexcept 的移动构造来决定是使用移动还是拷贝templateclass T void MySwap(T a, T b) noexcept(noexcept(T(std::move(a)))) { T tmp std::move(a); a std::move(b); b std::move(tmp); }这里出现了两个 noexcept但它们的含义完全不同内层noexcept 运算符noexcept(T(std::move(a))) 是一个编译期查询它在问编译器如果我用右值去构造一个 T 类型对象即调用 T 的移动构造函数这个过程会抛出异常吗如果移动构造函数标记了 noexcept它返回 true否则返回 false外层noexcept 说明符void MySwap(...) noexcept(bool-condition)这是一个函数承诺当括号内的条件为真时MySwap 会向编译器明确保证该操作绝不会抛出任何异常为什么 noexcept 对性能至关重要最经典的例子是vector 的扩容当 vector 空间不足需要扩容时面临一个关键决策是拷贝旧元素还是移动它们如果使用移动一旦移动到一半某个元素抛了异常旧的 vector 已经被破坏了无法回滚这违背了强异常安全保证解决方案vector 会利用 noexcept 运算符检测元素的移动构造函数当存在 noexcept 声明时可以安全地使用高效的移动语义否则为确保安全性只能采用效率较低的拷贝构造方式四. 标准库异常体系如果开发者随意定义异常类型如抛出 int 或 string 等不同类型main 函数的异常捕获逻辑将变得混乱不堪。为此C 专门提供了标准基类 std::exception 来规范异常处理1. 核心基类与家族谱系所有标准库异常都派生自 std::exception。它定义了一个极其重要的虚函数virtual const char* what() const noexcept;what()会返回一个描述错误原因的字符串。且作为异常体系的根基 what() 绝对不能再抛出异常因为 C 标准规定如果在异常处理的过程中特别是 what() 调用时再次抛出异常且未被处理系统会直接调用 std::terminate()为了防止在处理异常时再次产生异常。what() 必须返回const char*而不是std::string。因为std::string 的构造可能会因为内存不足而抛出std::bad_alloc而 const char* 仅仅是一个指针它是绝对安全的逻辑错误与运行时错误标准库将异常划分为两大类这种分类方式体现了对错误本质的深入考量1. std::logic_error逻辑错误这类错误理论上在程序运行前就能通过更严密的逻辑检查来避免。比如invalid_argument传参不对out_of_range数组越界length_error试图创建一个超出最大限制的对象如超长字符串2. std::runtime_error运行时错误这类错误无法通过预检完全避免它们依赖于外部环境或计算过程overflow_error / underflow_error算术溢出range_error计算结果超出范围2. 如何自定义异常在公司项目中通常会定义一套属于自己的异常体系但最好的做法是继承标准库这样我们的异常就能融入整个生态系统class MyException : public std::exception { public: // 1. 构造时传入错误信息 MyException (const std::string msg) : _msg(msg) {} // 2. 重写 what() virtual const char* what() const noexcept override { return _msg.c_str(); } private: std::string _msg; };当你在顶层捕获时只需要catch (const std::exception e)就能利用多态打印出无论是系统级如bad_alloc还是业务级如MyProjectException的所有错误描述异常的优缺点写到这里我们需要给异常机制定个性。它不是完美的但它是不可或缺的优点对比错误码异常如果你不处理程序就自杀。这逼着开发者必须考虑健壮性构造函数没有返回值异常是通知对象构造失败的唯一优雅手段正常的业务逻辑和错误处理逻辑实现了彻底分离缺点代码中的任何一行都可能抛出异常因此程序员必须编写异常安全的代码大量依赖RAII机制这带来了较高的认知负荷性能损耗尽管在正常情况下几乎不会产生额外开销但一旦抛出异常编译器需要进行调用栈回溯、查找异常表并执行析构操作。这种机制在实时性要求极高的场景如高频交易系统游戏内核中需要谨慎使用总结C 的异常机制本质上是一次关于错误处理权力的重新分配它将开发者从繁琐的错误码判断中解放出来通过非局部跳转与自动化的栈展开使错误处理与正常逻辑得以有效分离同时保证资源能够被正确释放尽管异常在抛出过程中存在查表与回溯的开销但通过noexcept约束编译器得以进行更激进的优化同时在构造函数失败等场景下异常机制也提供了其他手段难以替代的处理能力掌握异常机制意味着不仅理解其语法形式更能够在系统设计中借助多态异常体系与异常安全等级构建稳健的错误处理边界