C++ 的异常处理，说难不难，说简单也绝对不简单。我最初学的时候，觉得不就是try、catch、throw这三个关键字嘛，写几个 demo 就会了。但真正在项目里用起来，才发现坑一个接一个：析构函数里能不能抛异常、构造函数失败怎么办、noexcept到底该不该标、性能损失有多大、跟传统错误码怎么取舍……这些如果没人点拨，全靠自己踩坑，真的会花掉大量时间。这篇笔记，就是把我从入门到实际使用过程中，关于 C++ 异常这一块的思考和经验做一次系统梳理。适合刚学完 C++ 语法、想深入了解异常机制的初学者，也适合写了一些代码但遇到异常相关困惑的开发者。
先说清楚，这不是一篇教你背语法规则的文档，而是会告诉你异常机制的设计初衷、工作原理、实际编码时的最佳实践、以及那些教科书里不太会写的坑。
1. 异常机制的设计初衷与核心原理
1.1 异常到底解决了什么问题
先回到最原始的问题：函数执行出错时，怎么通知调用者？
最传统的做法是返回错误码。你看 C 语言的printf返回啥、fopen失败返回NULL、open失败返回 -1，都是这个套路。但错误码有一个天然痛点：你很容易忽略它，或者忘记处理它。比方说：
int result = doSomething(); // 如果 doSomething 返回 -1 表示失败，这里不检查，后面直接用 result // 结果就是带着错误的 result 继续往下跑，最终产生一个莫名其妙的结果写业务代码的人都有体会，错误码这种东西，检查多了代码全是if嵌套，不检查又埋雷。
异常机制的思路就是另一回事了：它把错误处理从正常的逻辑流里剥离出来，一旦有异常抛出，程序的执行流直接跳转到对应的catch块。你不需要在每一层都手动检查并向上传递错误，只要在合适的位置统一捕获就行。这种“天塌下来有人接着”的感觉，对代码结构的简化是很明显的。
另外，错误码没办法跨越运算符重载、构造函数、析构函数这些“函数的返回值已经另作他用”的场景。比如构造函数失败了，它没有返回值给你；而异常机制天然能处理这种场景。这就是为什么构造函数里碰到错误往往要抛异常，因为除了抛异常，你根本没法告诉调用者构造失败了。
1.2 栈展开（Stack Unwinding）的核心原理
异常的处理机制，有个重要概念叫“栈展开”。
想象一下，程序里有函数 A 调 B，B 调 C，C 里抛出一个异常。C 里没有捕获，异常就往上抛到 B，B 也没有捕获，再抛到 A。这个过程中，B 和 C 里那些已经构造好了的局部对象，需要被逐一析构。这种从当前函数栈帧逐层向上、一路析构局部对象、直到找到能处理这个异常的catch块的过程，就叫栈展开。
这是异常机制最核心、也最容易被忽略的机制。很多人问“为什么局部对象能自动释放”，答案是：栈展开时会自动调用局部对象的析构函数。
#include <iostream> #include <stdexcept> class Test { public: Test(int id) : id_(id) { std::cout << "构造: " << id_ << std::endl; } ~Test() { std::cout << "析构: " << id_ << std::endl; } private: int id_; }; void Level3() { Test t3(3); throw std::runtime_error("出现异常了"); } void Level2() { Test t2(2); Level3(); } void Level1() { Test t1(1); Level2(); } int main() { try { Level1(); } catch (const std::exception& e) { std::cout << "捕获异常: " << e.what() << std::endl; } return 0; }这段代码输出会依次是：
构造: 1 构造: 2 构造: 3 析构: 3 析构: 2 析构: 1 捕获异常: 出现异常了注意看顺序：先析构 Level3 里的 t3，然后是 Level2 的 t2，最后是 Level1 的 t1。这就是栈展开在起作用。如果你把代码跑一遍，看到这个输出顺序，对异常机制的理解会立刻上一个台阶。
1.3 异常的性能影响：该不该担心
一提到异常，很多人第一反应是“性能差”。这个说法有历史原因，早期 C++ 编译器的异常实现确实慢，但现代编译器普遍采用“零成本异常”（Zero-Cost Exception）模型，什么意思呢？
在零成本模型下，程序正常运行（即不抛异常）时，异常处理不会带来任何额外开销。可执行文件就多放了一些只在异常抛出时才会用到的元数据。真正的开销发生在抛异常的那一刻：
- 需要动态内存分配来构造异常对象？
- 需要执行栈展开、逐层寻找 catch 块；
- 可能需要展开大量的栈帧。
所以，异常的性能开销是“慢在异常发生时”，而不是“慢在正常执行路径上”。如果你的业务逻辑里异常本身就是非常罕见的情况，用异常处理错误完全不用担心性能。反过来，如果你把异常用在正常控制流里（比如依赖异常来结束一个循环），那就是性能灾难，因为异常的本质是“罕见事件”，不适合做常规流程控制。
提示：如果你听说“不要用异常，性能太差”，先分清对方说的是哪个年代的经验。现代 C++ 实践里，异常在“反馈超时、资源不足、非法参数”等场景下，是合理并且推荐的做法。
2. 异常语法基础与代码实操
2.1 抛出异常：三种 throw 写法
最常见的写法是直接throw std::runtime_error("错误描述")，但这其实是一个简写，完整的写法是构造一个临时异常对象再抛出。C++ 里有三种常见的 throw 场景：
// 第一种：直接抛匿名对象 throw std::runtime_error("文件不存在"); // 第二种：抛命名对象 std::logic_error err("参数不合法"); throw err; // 第三种：重新抛出（在 catch 块里） try { doSomething(); } catch (...) { // 做点记录，然后继续往外抛 throw; // 注意是 throw; 不是 throw e; }这里有个非常关键、也是新手最容易踩的坑：在 catch 块里重新抛出时，一定要用裸的throw;，而不是throw e;。
throw;会把当前捕获到的异常原封不动地再次抛出，保留原始的异常类型和内容。而throw e;会触发一次拷贝构造，生成一个新异常对象。如果 e 是基类类型，甚至还可能发生对象切片。更重要的是，如果当前捕获的是非类型不可拷贝的异常（比如一个不可复制的自定义类型），throw e;连编译都过不去。所以规则就是：在 catch 里想继续往外抛，一律写throw;。
2.2 catch 的匹配规则与注意事项
catch块的匹配规则不是“最接近的就行”，而是“第一个匹配到就执行，后面的不会再检查”。举例：
try { throw std::runtime_error("错误"); } catch (const std::exception& e) { std::cout << "捕获到 std::exception: " << e.what() << std::endl; } catch (const std::runtime_error& e) { std::cout << "捕获到 runtime_error: " << e.what() << std::endl; }输出是“捕获到 std::exception”，因为std::runtime_error继承自std::exception，第一个 catch 就匹配上了，第二个 catch 永远不会执行。所以写 catch 时，异常类型越具体的 catch 要放在越前面。
还有个细节：catch 的参数类型。一般推荐用const 引用来捕获，比如catch (const std::exception& e)，而不是catch (std::exception e)。为什么呢？因为按值捕获会触发一次拷贝构造，产生新对象；而且如果异常类型是某个派生类对象，按基类值捕获还会发生切片——你拿到手的异常对象已经丢失了派生类信息了。用引用捕获就没有这些问题。
一般来说，catch (...)（三个点）用来捕获所有异常，常用于兜底。但注意，catch (...)里你没法拿到异常的具体信息，只能做“记录日志，然后重新抛出”这类操作。还有一些编译器对catch (...)的处理比指定类型的 catch 要笨重一些，所以别贪方便到处用，兜底就行。
2.3 自定义异常类型的最佳实践
标准库提供的异常类型有限，业务里往往需要自定义异常类型。我的建议是：统一继承std::exception或std::runtime_error，并重写what()方法。
#include <exception> #include <string> class ConfigException : public std::runtime_error { public: explicit ConfigException(const std::string& message) : std::runtime_error(message) {} }; class NetworkException : public std::runtime_error { public: explicit NetworkException(const std::string& message) : std::runtime_error(message) {} };这样自定义异常类型可以直接用catch (const std::exception& e)捕获，也能被catch (...)兜住，整个调用链对异常类型的认知保持一致，不用为每种异常写一套独立的处理逻辑。
有人喜欢在自定义异常里添加各种字段，比如错误码、错误数据等。这没问题，但你得想清楚：抛出异常本身是一个“跨函数边界”的操作，异常对象会经过拷贝/移动，字段太多、太重，拷贝成本也上去了。我一般只在异常类型里放一个字符串消息，额外数据放在catch之后取出来处理。
注意：自定义异常类的构造函数里，字符串参数的传递用
std::string就好，别为了省一次拷贝写出const char*+ 局部分配的复杂逻辑。这里不需要过度优化。
3. 异常安全与资源管理
3.1 异常安全等级：代码质量的分水岭
异常安全这个概念，是衡量代码“在发生异常时能否保持正确状态”的指标，分三个等级：
- 基本保证（Basic Guarantee）：异常发生时，对象处于合法但不确定的状态。也就是说，对象还能安全析构和赋值，但你不知道具体值是什么。
- 强保证（Strong Guarantee）：异常发生时，对象状态保持不变，要么操作完全成功，要么完全没发生，像事务一样回滚。
- 无异常保证（No-Throw Guarantee）：操作承诺永远不会抛异常，比如
int的拷贝、std::unique_ptr的析构。
写生产级代码，至少要追求“基本保证”，核心操作最好做到“强保证”。比如：
class DataBuffer { public: void append(const std::vector<int>& data) { // 先构造一个临时对象，全部处理好 std::vector<int> temp = data_; temp.insert(temp.end(), data.begin(), data.end()); // 全部成功后再赋值，赋值操作如果不抛异常，这就实现了强保证 // 但 vector 的拷贝赋值是有可能抛异常的，所以这里只能算基本保证 data_ = std::move(temp); } private: std::vector<int> data_; };这种“先改副本，成功后一次性替换”的手法，是实现强保证的经典方式，也就是 copy-and-swap 思路。
但说句实在话，强保证不是每次都能做到。比如操作涉及多个对象、多个步骤时，中间某一步失败，前面已经改了的数据没法回滚。这种时候要有清晰意识：哪个函数提供什么级别的保证，注释里写清楚，别让调用者猜。
3.2 RAII 思想：资源管理的核心武器
RAII（Resource Acquisition Is Initialization），中译“资源获取即初始化”，是 C++ 里处理资源最核心的思想。简单说就是：资源在构造函数里获取，在析构函数里释放。因为栈展开时析构函数一定会被调用，所以只要资源管理遵循 RAII，即使在异常发生的路径上，资源也能被正确释放。
看个反面教材：
void bad_example() { int* ptr = new int(42); // 这里如果抛异常，ptr 就泄漏了 doSomething(); delete ptr; }doSomething()一旦抛异常，delete ptr;永远不会执行，ptr指向的内存就泄漏了。改正方法是使用智能指针，或者自己封装一个 RAII 类：
void good_example() { std::unique_ptr<int> ptr = std::make_unique<int>(42); // 即使 doSomething 抛异常，ptr 的析构函数也会自动释放内存 doSomething(); }这个思想不限于内存管理。文件句柄、锁、数据库连接，凡是能想到的资源，都能用 RAII 来管理。比如std::lock_guard就是典型的 RAII：构造函数里加锁，析构函数里解锁。就算临界区里抛了异常，锁也会被正确释放，不会死锁。
所以每当你写一个类，如果构造函数里拿了资源（打开文件、加锁、分配内存、建立连接），第一反应就应该是：析构函数里老老实实地释放，而且析构函数绝不能抛异常。
3.3 析构函数中的异常：绝对禁区
这是异常处理里最需要刻进 DNA 的一条规则：析构函数千万不要让异常逃出去。
为什么？因为在栈展开期间，析构函数是被“顺带”调用的。如果在已经处理一个异常的过程中，析构函数又抛出一个新的异常，C++ 标准会直接调用std::terminate，程序立即终止，连挽救的机会都没有。这种问题极难排查，因为日志里根本看不出所以然，只能看到进程突然崩了。
~DataBaseConnection() { try { close(); } catch (...) { // 这里必须捕获所有异常，至少不能让异常从析构函数逃出去 // 标准做法是记日志或吞掉，但不能传播 std::cerr << "析构时关闭连接失败，忽略" << std::endl; } }很多时候，析构函数里清理资源的操作确实可能抛异常（比如 flush 数据库连接时网络断开），这时你有几个选择：
- 在析构函数内部捕获所有异常，不往外传播；
- 提供一个单独的
close()方法，把可能抛异常的操作交给调用者主动调用； - 析构函数里只做绝对不会抛异常的释放操作。
实际项目里最常使用的是前两种的组合：析构函数调用close()的时候，close()内部自己捕获并处理异常，或者析构函数里把close()包在 try/catch 里。
4. 常见陷阱与排查经验
4.1 构造函数失败：抛异常与二段式构造的博弈
构造函数没有返回值，这是它没法用错误码上报失败的根本原因。那构造函数失败怎么办？有两个流派：
- 流派一：构造函数里抛异常，这是 C++ 里最合理的做法。构造失败意味着对象根本没建立成功，后续不再需要担心一个半死不活的对象被继续使用。而且 C++ 机制保证：构造函数的函数体抛异常时，已经构造完的成员变量会被自动析构，不会造成成员资源泄漏。
- 流派二：二段式构造，即构造函数只做最简单初始化，再提供一个
init()方法做完整初始化，用返回值上报结果。这种做法在旧代码里很常见，但现代 C++ 强烈不推荐，因为二段式构造会导致“对象创建成功但没初始化完成”的中间状态，所有方法都得多加一层判断，代码复杂性剧增。
所以我的建议是：能抛异常就抛异常，别搞二段式构造。如果担心构造函数抛异常时资源泄漏，用 RAII 类管理成员（比如用std::string代替char*，用智能指针代替裸new），析构函数和成员销毁都是自动的。
4.2 noexcept 关键字：承诺不抛异常就要做到
noexcept是 C++11 引入的关键字，用来告诉编译器“这个函数保证不抛异常”。怎么用的？
void simple_swap(int& a, int& b) noexcept { int tmp = a; a = b; b = tmp; }加了noexcept之后，编译器就知道这个函数不会抛异常，可以做更多优化：容器在扩容时，如果元素类型的移动构造函数是noexcept的，就可以放心大胆地移动元素，否则只能退回到拷贝，性能会有明显差距。
但是——这是重点——如果noexcept函数真的抛了异常，程序会直接调用std::terminate终止，而不是让你捕获。这相当于一个“合同”，一旦签了就得遵守。
常见场景：
- 移动构造函数、移动赋值运算符，尽量标
noexcept； swap函数尽量标noexcept；- 析构函数默认就是
noexcept的（除非你显式写成noexcept(false)），所以别让析构函数抛异常，否则就是 terminate； - 你不确定会不会抛异常的函数，就别标
noexcept，这是一个“宁可保守，不要冒险”的场景。
我还见过一些代码为了性能到处标noexcept，完全不考虑函数内部调用了哪些可能抛异常的操作。这类代码一旦遇到异常就是直接崩溃，比不标更危险。标noexcept前，请把函数体内所有函数调用都理一遍，确保没有异常会跑出来。
4.3 catch 块里最常见的两个低级错误
低级错误一：catch 后什么都不做，直接吞掉异常。
try { loadConfig(); } catch (...) { // 这里什么都没做 }这叫“吞异常”（Exception Swallowing）。异常被吞掉之后，程序会继续跑，但此时可能已经处于错误状态了。更麻烦的是，这种错误几乎不可排查，因为没有任何日志。我建议：如果确实想忽略某个异常，请在 catch 块里至少写一行日志，说明你捕获了什么、为什么忽略。日后排查问题时，这行日志就是救命稻草。
低级错误二：在 catch 块里又抛用了不合适的异常类型。
try { doSomething(); } catch (const std::exception& e) { throw "字符串异常"; // 你在抛一个 const char*，不是 exception 类型 }抛出字符串这种做法会让调用者无从处理，除非他用catch (...)通吃。生产代码里，请统一抛出std::exception派生类，让异常类型体系保持一致。
4.4 数组越界与 STL 容器的异常行为
热词里很多人搜“数组越界异常”，这里多说两句。原生 C++ 数组（比如int arr[10]）是没有边界检查的，越界访问是未定义行为，不会抛任何异常，可能直接踩到别的内存导致崩溃。而 STL 容器的at()成员函数是有边界检查的，越界会抛出std::out_of_range：
#include <vector> #include <iostream> int main() { std::vector<int> nums = {1, 2, 3}; try { std::cout << nums.at(10) << std::endl; // 会抛 std::out_of_range } catch (const std::out_of_range& e) { std::cout << "越界: " << e.what() << std::endl; } return 0; }注意operator[]（比如nums[10]）同样不检查边界，行为未定义，不抛异常。所以如果你希望有异常保护，用at()而不是operator[]。不过at()有轻微性能开销，追求极致性能的代码内部依然用operator[]也不少见，关键是做好边界判断。
4.5 日志与异常的配合
异常有一个天然的痛点：它只告诉你“错误是什么”，不告诉你“错误在哪发生”。比如std::runtime_error("连接超时")，你只知道连接超时了，但不知道是哪个模块、哪一行抛出来的。排查这类问题，日志配合非常重要。
我的做法是在 catch 关键边界的地方，把异常信息和当前上下文记录下来：
try { processRequest(data); } catch (const std::exception& e) { // 记录模块名、函数名、操作描述和异常信息 std::cerr << "[RequestHandler::process] 处理请求失败: " << e.what() << std::endl; throw; // 如果需要继续上报，就重新抛出 }如果某些场合不需要继续抛出，记录日志之后可以直接吞掉，但要写明原因。异常处理最忌讳“默默无闻地失败”，因为这种问题会变成半夜两点把你叫醒的线上事故。
5. 生产者视角：异常规范与项目实践
5.1 标准异常体系速查
C++ 标准库的异常体系，根子是std::exception，下面分几条线：
| 异常类型 | 继承自 | 典型场景 |
|---|---|---|
std::bad_alloc | std::exception | 内存分配失败（new失败） |
std::bad_cast | std::exception | dynamic_cast失败，多态类型转换失败 |
std::out_of_range | std::logic_error | at()越界、容器元素访问越界 |
std::invalid_argument | std::logic_error | 参数类型合法但是值不合理 |
std::length_error | std::logic_error | 长度超过容器最大允许值（比如字符串 resize 到极大） |
std::runtime_error | std::exception | 运行时错误，业务异常基类最常用这个 |
std::system_error | std::runtime_error | 系统调用错误、操作系统错误 |
实际项目里，如果不想继承std::runtime_error，继承std::exception也没问题，但两者有区别：std::runtime_error的构造函数接收一个const std::string&，你直接传描述文本就行，它的what()返回这个字符串；而std::exception默认构造函数不接受字符串，要想让what()返回自定义描述，得自己维护字符串成员、自己重写what()。绝大多数情况下，继承std::runtime_error省事得多。
5.2 异常 vs 错误码：什么时候用哪个
这是 C++ 社区讨论最热烈的问题之一。我目前实践下来的经验是：分层看待，不搞一刀切。
- 可能恢复的错误：比如用户输入有误、文件不存在但用户可以重新选择、网络暂时不可用但可以重试。这类错误用错误码或返回值更合适，因为调用者本来就必须处理这个情况。
- 不可能恢复或不该继续的错误：内存不足、配置严重错误、内部状态不一致。这类错误用异常更合适，因为调用者大概率没有能力恢复，不如一路抛出去，在顶层统一记录日志并终止操作。
还有一种说法：异常是“非本地控制转移”，如果错误处理逻辑就在错误发生点附近，错误码更直接；如果错误需要跨越多个调用层级才能被合理处理，异常更省事。
以我的偏好，业务代码里，我倾向于在模块边界使用异常。模块内部的数据处理尽量用返回值和 optional，因为模块内的错误通常是可预期的逻辑错误，不值得每步都用异常砸一遍。而模块之间的调用（比如服务层调数据访问层），如果数据访问层发生严重问题，抛异常出来让上层统一处理，比层层传递错误码干净很多。
提示：现代 C++ 里还有个中间形态，
std::optional和std::expected（后者在 C++23 标准库落地）。如果返回值可能没有，但不是一个“严重错误”，优先用std::optional；如果需要携带错误信息，可以看std::expected。它们比异常轻量，又比裸错误码安全。
5.3 异常的跨模块边界：动态库的挑战
这是写大型项目时绕不开的一个坑：异常跨 DLL/动态库边界的兼容性问题。
不同编译器、不同标准库实现、甚至不同编译选项下，异常的类型和栈展开规则可能不完全一致。如果模块 A 用 MSVC 编译，模块 B 用 MinGW 编译，A 抛出的异常到 B 里可能无法被正确捕获，甚至直接崩溃。
解决思路：
- 尽量在同一套工具链下编译所有模块；
- 确保都使用相同的异常模型（比如 MSVC 的
/EHsc设置）； - 如果确实没法统一，在动态库边界改用错误码或返回对象来传错误，而不是让异常跨边界。
这个坑在新手阶段很难遇到，但面试或者接手大型项目时经常会问到，提一嘴大家有个印象。
5.4 异常陷阱速查表
做了一张表，汇总了我实际开发中遇到过的异常相关坑，对照自查用：
| 陷阱描述 | 危害 | 建议处理方式 |
|---|---|---|
| 析构函数抛异常 | 栈展开期间再抛异常直接 terminate | 析构函数内 try/catch 吞掉异常并记日志 |
| catch 顺序错误（基类在前） | 派生类异常永远捕获不到 | 具体类型放前面，基类放后面 |
| 吞异常不记录 | 程序在错误状态下继续跑，问题无法追踪 | 至少记一句日志 |
| 构造函数失败不抛异常 | 产生“半初始化对象”，到处都是中间状态 | 构造函数抛异常 |
裸new后不释放，而中间又可能抛异常 | 内存泄漏 | 用std::unique_ptr/ RAII 管理 |
| 过度使用异常做控制流 | 性能差、代码难以理解 | 正常的逻辑分支用 if 判断，别靠异常 |
在 catch 里用throw e;重新抛出 | 切片/丢失原始类型 | 用throw; |
| 动态库跨边界抛异常 | 类型不匹配导致崩溃 | 统一工具链或改用错误码 |
函数标了noexcept但内部抛异常 | 直接 terminate | 不确认就不标 noexcept |
这张表我经常翻看，每次看到都能想起当时踩坑的场景。你要是把这些坑都提前避开了，写 C++ 异常相关的代码会省心非常多。
6. 从入门到进阶：学习路线建议
6.1 如何一步步吃透异常
如果你现在刚接触 C++ 异常，我的建议是按下面这条路线走，每一步都有明确目标，别跳步：
第一步是完全掌握语法。try、catch、throw三个关键字能熟练使用，知道 catch 参数的引用捕获和值捕获区别。
第二步是用小 demo 验证栈展开。自己写几个类，分别在多个层级构造对象、析构对象，然后在最里层抛异常，观察析构顺序。这一步做完，你对“异常机制会自动清理局部对象”会有切身体感。
第三步是学会写自定义异常类型，统一在业务代码里使用。别一开始就往项目里加，先在一些小工具类里用起来，慢慢习惯。
第四步是理解异常安全等级，重构自己的代码。把裸指针替换成智能指针，把资源管理改成 RAII，保证每一个类在异常路径下都能正确释放资源。
第五步是读标准库源码。选一个常见容器（比如std::vector）的 push_back 实现，看看里面的异常处理逻辑，看看它怎么保证强异常安全。这个阶段对读码能力提升会很显著。
6.2 推荐的调试方法
调试异常相关代码，有一些专门的小技巧：
技巧一：利用调试器的“捕获第一次异常”功能。在 Visual Studio 里打开“Exception Settings”，勾选 C++ Exceptions，调试器在异常第一次抛出时就会中断，而不是等到栈展开到 catch 才停。这样你能看到异常最初是在哪一行抛出的，这一手排查看看堆栈特别有用。GDB 下对应的命令是catch throw。
技巧二：用日志记录异常传播路径。在每个 catch 块里记录日志，运行后能通过日志还原异常从抛出到捕获的完整路径。很多线上问题排查靠的就是这个。
技巧三：给异常对象加上必要上下文信息。比如在what()里带上模块名、函数名或关键参数。异常消息里包含的信息越多，排查越容易。比如"连接超时 (server=10.2.3.4, timeout=5s)"比"连接超时"有用得多。
6.3 学习资源与后续方向
C++ 异常处理这块，我的经验是看官方资料 + 读优秀的开源代码 + 自己动手写，三者结合。
官方资料方面，cppreference.com的 Exception 相关页面写得非常详细，比任何二手资料都权威。开源代码方面，建议找一个你熟悉的 C++ 开源项目，搜索代码里的throw、catch、noexcept，看看别人是怎么组织异常体系的，收益会非常大。
自己动手的话，可以尝试实现一个小型配置解析器，或者一个简单的线程池，然后在里面用异常处理各种错误场景。这种小项目既能锻炼异常处理的能力，又能练习资源管理，一举两得。
C++ 异常机制跟 C++ 的 RAII、移动语义、智能指针是紧密相关的。把异常吃透，等于把 C++ 的资源管理和错误处理体系打通了一半。后续如果想继续深入，可以研究std::variant和std::optional作为异常之外的错误处理方案，对比它们和异常的区别，会形成一个更完整的知识图谱。
我自己在这条路上的实际体会是：写了几年 C++，那些在网上吵得不可开交的“异常 vs 错误码”之争，放到真实项目里其实很有答案。异常是一个错误传播工具，它的价值不在于“用得越多越好”，而在于在合适的分层边界上，把确实属于异常情况的错误准确传递出来。你有没有正确理解栈展开、有没有让析构函数保持 noexcept、有没有注意 catch 的匹配顺序、有没有给异常对象补充足够的上下文——这些细节，决定了你的 C++ 代码在出错时是“崩溃后一脸懵”还是“日志一目了然”。
最后再分享一个小技巧：我写代码时有个习惯，凡是自定义异常类型，消息里一定要带上模块名。比如“ConfigLoader: 配置文件不存在: /etc/app.yaml”。这个习惯帮我省了无数次排查时间，建议你也试试。
