写 C 的时候错误处理是绕不开的一道坎。很多人第一反应是写return -1或者打日志但一旦项目复杂起来这种靠约定和返回值吃饭的方式迟早会被某个没检查返回值的调用点坑到深夜。stdexcept这顶帽子C 标准库里早已备好专门用来给程序提供一套成体系的异常类型。你不需要自己从零定义什么MyError直接拿标准库里现成的std::invalid_argument、std::runtime_error、std::out_of_range这些类就能把“参数错了”“运行期出事了”“下标越界了”这类高频错误清晰、规范地抛出去、接得住。这篇文章适合两类人。一是刚接触 C 异常机制、想搞明白标准异常类怎么用、怎么选的新手二是已经在项目里写了好几年错误处理、想把手上的错误码体系或者零散throw std::exception换成更严谨方案的开发者。我会从stdexcept的类型体系讲起再讲什么时候用哪一类、消息怎么写、捕获顺序怎么排、以及哪些坑我实测过一定会踩最后给一份可以直接照着用的实操方案。1. 项目整体设计思路为什么标准异常类比自造异常更靠谱1.1 从“错误码”到“异常”的切换动机先聊一个很多团队都经历过的场景。早期项目规模小接口就几个大家约定“返回 0 表示成功返回负数表示具体错误码”。代码写起来短平快出错时调用方if (ret 0)一下就能拦住。但随着接口变多、嵌套变深问题就来了函数 A 调用函数 BB 失败返回 -1A 忘记检查继续往下跑最后在 C 里段错误了。你查半天发现最早出错的地方离崩溃点隔了十几层调用。这种时候异常机制的核心价值就体现出来了——错误信息可以沿调用栈一路向上传播中间即使有代码没显式处理也不会立刻让程序陷入未定义行为而是会在某个合适的catch点被统一接管。stdexcept里的异常类本质上是一套“已分类的错误语义”。它不解决所有错误处理问题但它把最常见、最通用的一批错误类型提前替你想好了。比如函数收到一个负数半径你抛std::invalid_argument(radius must be non-negative)任何人一眼看到类型名就能明白这是参数非法。比起自定义一个MyProjectError还要在文档里解释ErrorCode::kBadArg是什么意思标准异常类的名称本身就是文档。1.2 为什么选stdexcept而不是自定义异常基类有人会问既然要抛异常为什么不统一抛std::exception或者定义一个项目自己的BaseException我的观点是std::exception太泛捕获之后你还是得靠what()字符串去区分错误类型本质上退回到了“靠约定”的路子。而自定义异常类最大的麻烦在于你需要自己处理what()返回什么字符串、怎么管理消息内存、拷贝构造函数怎么写、析构函数要不要noexcept。这些琐碎细节标准库已经帮你兜好了你继承std::runtime_error或std::logic_error之后只需要把错误消息传给构造函数即可。更重要的是标准库算法和容器在抛出异常时用的就是stdexcept这一套。比如vector::at()越界抛std::out_of_rangestoi转换失败抛std::invalid_argumentregex匹配出错抛std::regex_error它是std::runtime_error的派生类。如果你自定义一套完全不相关的异常体系就面临一个尴尬你没法在同一个catch里同时统一处理标准库的异常和自己的异常除非你在公共基类上做文章。而stdexcept的所有类都派生自std::exception这意味着你把catch (const std::exception e)写在最外层就能兜住标准库、第三方库、以及你自己遵循同一体系抛出的所有异常这是自造异常体系很难白嫖到的优势。2. 核心细节解析与实操要点stdexcept 异常家族怎么看怎么选2.1 两个分支logic_error 与 runtime_errorstdexcept头文件里一共有六张主要面孔分属两大分支。逻辑错误用std::logic_error及子类运行期错误用std::runtime_error及子类。记住这个二分法很重要因为它不是随意划分的它对应的是“理论上程序写对就不会发生”和“程序写对了也可能因为外部环境导致出错”这两种本质不同的场景。logic_error家族的成员有std::invalid_argument参数非法、std::domain_error数学域错误比如对负数开平方、std::length_error长度超出允许范围比如string::resize超过最大长度、std::out_of_range下标或迭代器越界。这一类的共同点是错误原因是程序逻辑本身的问题通常是调用方的错。如果你提供一个函数double sqrt_discriminant(double d)里面if (d 0) throw std::domain_error(negative discriminant);这就把“输入非法”这个事实非常明确地传达给了调用方。runtime_error家族的成员有std::range_error计算结果超出浮点表示范围不常用、std::overflow_error算术上溢、std::underflow_error算术下溢。这类错误的特点是代码逻辑可能完全正确但输入数据或运行环境超出了预期。比如你要解析一个外部文件里的数字文件内容被改坏了stoi抛std::invalid_argument这属于参数类问题但如果文件数值大得离谱到后面做浮点运算溢出那就是overflow_error的领土。2.2 构造函数与 what() 消息的隐藏细节每个stdexcept异常类的构造函数都接受一个const std::string或者const char*参数用于设置what()返回的消息。这里有个实际开发中容易忽略的点异常对象在抛出时会把消息字符串拷贝内部生命周期不依赖你传入字符串的存活情况。所以你可以放心传一个临时构造的std::string比如int parse_port(const std::string input) { int port 0; try { port std::stoi(input); } catch (const std::invalid_argument e) { throw std::invalid_argument(invalid port: input); } if (port 1 || port 65535) { throw std::out_of_range(port out of range: std::to_string(port)); } return port; }这里把原始输入拼进消息里是很有价值的调试习惯。很多人在现场排查问题时最恨的就是看到一句干巴巴的invalid port不知道到底是哪个端口、哪个配置文件里的值引起的。所以我的建议是what()里至少要包含三件事错误类型关键词、触发这个错误的上下文数据、以及必要的期望范围或约束信息。比如上面port out of range: 70000一眼就懂。namespace std { class invalid_argument : public logic_error { public: explicit invalid_argument(const string __arg); explicit invalid_argument(const char* __arg); }; }标准只要求构造函数存在没强制规定它必须把消息拷贝一份所以从极端严格的角度讲what()返回的指针是否一直有效取决于实现。但在所有主流标准库实现里消息都会被拷贝管理你可以安全地保留这块指针。不过我还是不建议长期保存e.what()返回的指针最好是在捕获异常后立刻把它拷贝到自己的std::string里再继续处理。实操心得异常消息里尽量避免拼接二进制数据或者大数组内容否则一旦异常路径被高频触发日志量会非常吓人。拼接关键标量值、文件名、ID 这类轻量信息就够了。2.3 捕获顺序中的切片与多态陷阱很经典的一个坑catch子句按顺序匹配先到先得。所以如果你写try { vec.at(100); } catch (const std::exception e) { std::cerr exception: e.what() \n; } catch (const std::out_of_range e) { std::cerr out of range: e.what() \n; }第二个catch永远不会执行因为std::out_of_range是std::exception的派生类会先被基类接住。正确做法是把最具体的类型写在最前面把基类写最后做兜底。这个顺序错误不会导致编译报错大多数时候只是让更具体的分支静默失效属于那种很容易留到上线的隐患。另一个与之相关的坑是异常对象的切片问题。stdexcept异常类本身没有虚析构之外的额外大对象但一旦你写出这样的代码catch (std::exception e) // 按值捕获异常对象会被切片成基类派生类型信息彻底丢失。你只能用e.what()没法再判断它到底是out_of_range还是invalid_argument。捕获异常必须用引用最好是const引用。这既是性能问题避免拷贝也是类型保持问题避免切片。这个习惯我从开始写 C 就坚持到现在已经变成肌肉记忆了。3. 实操过程与核心环节实现一套能落地到现有项目的异常处理方案3.1 五种典型场景下的异常选择速查我整理了一个平时写代码时手边会过一遍的选择清单不一定适合所有项目但覆盖面很广场景推荐异常类型典型消息格式参数为空指针、非法数值、非法枚举值std::invalid_argumentxxx must be ...数学运算超出函数定义域std::domain_errorsqrt requires x 0下标访问越界vector::at是现成例子std::out_of_rangeindex 10 out of range [0, 5)容器或字符串操作要超长扩容std::length_errorresize exceeds max_size外部数据格式错误、解析失败、IO 失败等运行期问题std::runtime_errorfailed to read config: ...数值运算溢出、除零后结果超范围std::overflow_errorinteger overflow at ...一句话记忆方式凡是调用方传参非法导致的基本往logic_error分支靠凡是环境或外部数据导致的基本往runtime_error分支靠。3.2 项目级异常处理框架中间层包装与统一日志单纯会throw和catch不算完真实项目需要一个稳定的异常处理骨架。我常用的思路是三层结构。底层是功能函数负责检查输入、执行逻辑发现问题就直接抛stdexcept。中间层是业务调用方一般在函数入口处不接异常让它自然向上传播只有当错误需要在当前层补充上下文信息比如当前操作的文件名、账号 ID时才重新包装抛出void load_user_settings(int user_id) { try { auto path build_config_path(user_id); auto content read_file(path); parse_settings(content); } catch (const std::runtime_error e) { throw std::runtime_error(failed to load user settings for user std::to_string(user_id) : e.what()); } }最上层是唯一的异常出口通常在主函数入口或者线程入口处写一个try-catch捕获std::exception记录日志返回错误码或者触发兜底逻辑。这样设计的好处是异常不会被一路打日志打出几十条重复信息而是每一层只补一条关键上下文最上方统一落盘一条完整链路。日志量可控问题定位也很快。3.3 与 RAII 结合不要在析构函数里抛异常C 的异常安全离不开 RAII但 RAII 的析构函数里有个死规矩析构函数默认不能抛异常或者至少不能让异常逃逸。std::vector的析构函数在清理元素时如果元素析构抛异常程序会直接调用std::terminate。所以你在写自己的资源管理类时~MyFile、~MyConnection内部绝对不能抛stdexcept或任何异常。那资源释放失败怎么办我的实践是释放资源时出错先记录警告日志实在不行就用一个单独的close()方法暴露给调用方让它有机会在正常执行路径中检查关闭结果并处理错误。析构函数只做“最保守的释放动作”绝对不把异常往外传。这个习惯能避免一大半神秘的崩溃问题。引用 Scott 式的经验说法就是析构函数里写throw等于把程序的命运交给了terminate。3.4 性能视角异常路径不该是主流程有些人一听到异常就害怕性能开销这很正常毕竟早年 C 异常实现确实有额外成本。但现代编译器普遍采用零成本异常模型zero-cost exception handling只要你不抛出异常正常路径上几乎没有额外开销代价都体现在异常表数据段和真正抛异常时的栈展开过程。所以性能关键路径上你可以放心用异常来报错只要保证异常事件是“罕见事件”即可。但如果你是写一个每秒调用几百万次、并且预期每次调用都会有大量非法输入的函数那这套方案可能不适合。比如一个解析指令的函数用户输入数据脏得离谱合法率只有 60%。这种情况更合理的设计是返回std::optional或错误码把异常路径当作真正的“意外事件”来用。判断标准很简单异常应该是少数情况的逃逸出口而不是主流程控制器。4. 常见问题与排查技巧实录4.1 为什么 catch 到了异常但信息是空的有朋友遇到过这种情况e.what()返回空字符串。排查步骤一般是三步。第一步确认抛出时是否传了消息第二步确认是不是某个库内部抛了一个不带消息的异常比如std::bad_alloc在某些实现下默认消息就是std::bad_alloc还好但某些第三方库可能直接throw std::runtime_error()第三步检查是不是捕获时把异常切了片但切片不会影响what()所以这步主要是排空字符串的直接原因。真正解决这个问题的方向只有一个所有throw语句必须带上有效消息并且代码评审时把“异常消息是否提供了上下文”列为检查项。4.2 noexcept 函数里异常逃逸导致的 terminateC11 之后一个函数如果被标记为noexcept它内部一旦抛出异常不会沿着调用栈找catch而是直接std::terminate。这个行为太坑了。常见的典型问题是移动构造函数有时会被隐式标成noexcept如果移动构造里抛了异常程序直接终止没有挽回余地。我在实际项目里碰到过一个问题某个类内部持有std::vectorstd::string默认生成的移动构造按规则会带noexcept但我在自定义移动构造里调了一个可能抛std::bad_alloc的函数编译器没帮我禁止运行时才炸。排查方法也很直接看到terminate调用栈先查哪些链路被noexcept约束了然后把不保险的函数上的noexcept去掉或者在其内部用try-catch包住所有可能抛异常的调用。4.3 第三方库异常与本项目异常体系的融合项目里用了很多第三方库它们抛出的标准异常类型一般能直接捕获。但有些库会抛自定义异常不继承std::exception比如某些 C 库会直接返回错误码混合线程模型下异常可能跨 DLL 边界传播出问题。面对这种情况我没法给出一个万能方案但可以分享一个稳妥思路在自己代码的边界处做一层异常转换。// 库边界转换示例 void call_third_party_api() { try { third_party::do_something(); } catch (const std::exception e) { throw std::runtime_error(std::string(third_party do_something failed: ) e.what()); } catch (...) { throw std::runtime_error(third_party do_something failed: unknown error); } }这样项目的所有上层代码只需要面对std::exception一个体系不需要为某个第三方库写一套专属 catch 逻辑。缺点是要多写一层包装代码但换来的是调用方的统一体验我认为非常值。4.4 调试技巧怎么快速找到是哪个 throw 抛出来的当异常类型对了、消息也对了但还是想立刻定位到出错的精确位置时靠日志不够快。我的习惯是在开发阶段给编译参数加-fno-omit-frame-pointer同时配合调试器在异常抛出点断住。如果使用 GDB可以用catch throw命令让程序在每一个异常抛出时自动停下再通过bt看完整调用栈。这在排查那些“消息正确但位置可疑”的异常时特别有效能省掉大半天打日志的时间。另一个小技巧是不要在what()里写自己都不懂的缩写。曾经排查一个月前的代码看到一句idx err愣是想不起来这个idx是指容器下标还是配置条目编号。后来改了规则消息里的上下文字段名必须与代码变量名保持一致比如index 100 out of range, vector size is 5这种变量名和值都出现在消息里半年后回头看你依然能瞬间理解。4.5 完整实操示例一个参数校验 文件解析的异常处理模板最后给一份可以直接抄走的模板它涵盖了本文提到的大部分要点#include iostream #include stdexcept #include fstream #include string #include vector class ConfigLoader { public: explicit ConfigLoader(const std::string path) : path_(path) {} // 对于可能出现参数错误和运行期错误的接口分别抛不同类型 std::vectorint load(); private: std::string path_; }; std::vectorint ConfigLoader::load() { if (path_.empty()) { throw std::invalid_argument(ConfigLoader: path is empty); } std::ifstream in(path_); if (!in.is_open()) { throw std::runtime_error(ConfigLoader: cannot open file: path_); } std::vectorint result; std::string line; int line_num 0; while (std::getline(in, line)) { line_num; try { int value std::stoi(line); result.push_back(value); } catch (const std::invalid_argument) { throw std::runtime_error(ConfigLoader: invalid integer at line std::to_string(line_num) : line); } catch (const std::out_of_range) { throw std::runtime_error(ConfigLoader: integer out of range at line std::to_string(line_num) : line); } } if (result.empty()) { throw std::runtime_error(ConfigLoader: no integer values found in path_); } return result; } int main() { try { ConfigLoader loader(config.txt); auto values loader.load(); for (int v : values) { std::cout v \n; } } catch (const std::invalid_argument e) { std::cerr config error: e.what() \n; return 1; } catch (const std::runtime_error e) { std::cerr runtime error: e.what() \n; return 2; } catch (const std::exception e) { std::cerr unknown exception: e.what() \n; return 3; } return 0; }注意std::stoi可能抛std::invalid_argument字符串不是数字和std::out_of_range数字超出int范围。这里我把运行期加载上下文的错误统一改写成std::runtime_error因为对上层调用方来说“配置文件某一行的数字有问题”本质上是外部数据导致的运行期错误而不是调用方传参错误。5. 让我最后再分享几点实际体会用stdexcept这几年我最大的感受是它把“错误是什么”这件事变得非常可读。以前看到return -1你得翻文档查错误码表现在看到catch (const std::out_of_range)类型本身就说明了一切。自定义异常当然有自己的价值但绝大多数项目里的错误其实都逃不出标准库这几个分类。先把这套标准玩熟再去定制项目专属异常路子会顺很多。一个很容易被忽略的后期收益是当团队的代码库里异常类型统一、消息格式规范之后日志聚合系统自动按异常类型做统计就变得非常轻松。哪个模块总抛invalid_argument、哪里频繁出现runtime_error一目了然。这比我当初靠 grep 各种错误码字符串来摸情况舒服太多。最后再交底一个小技巧如果你要在一个已经用了多年错误码的老模块里逐步引入异常不要一次性把接口全改了。先选一个出错率最高的内部函数把它的错误码改造成stdexcept异常然后在上层调用处捕获并转换成原来的错误码保持对外接口不变。这样既用上了异常的自然传播和上下文拼接又不至于让整个模块在一天内推倒重来。边角细节慢慢磨等到团队对异常行为的预期一致了再决定要不要彻底全线迁移。 
长河君 · 2026/10/20 17:04:58 · 阅读 1.2k C++ stdexcept异常处理实战：从错误码到标准异常体系
写 C 的时候错误处理是绕不开的一道坎。很多人第一反应是写return -1或者打日志但一旦项目复杂起来这种靠约定和返回值吃饭的方式迟早会被某个没检查返回值的调用点坑到深夜。stdexcept这顶帽子C 标准库里早已备好专门用来给程序提供一套成体系的异常类型。你不需要自己从零定义什么MyError直接拿标准库里现成的std::invalid_argument、std::runtime_error、std::out_of_range这些类就能把“参数错了”“运行期出事了”“下标越界了”这类高频错误清晰、规范地抛出去、接得住。这篇文章适合两类人。一是刚接触 C 异常机制、想搞明白标准异常类怎么用、怎么选的新手二是已经在项目里写了好几年错误处理、想把手上的错误码体系或者零散throw std::exception换成更严谨方案的开发者。我会从stdexcept的类型体系讲起再讲什么时候用哪一类、消息怎么写、捕获顺序怎么排、以及哪些坑我实测过一定会踩最后给一份可以直接照着用的实操方案。1. 项目整体设计思路为什么标准异常类比自造异常更靠谱1.1 从“错误码”到“异常”的切换动机先聊一个很多团队都经历过的场景。早期项目规模小接口就几个大家约定“返回 0 表示成功返回负数表示具体错误码”。代码写起来短平快出错时调用方if (ret 0)一下就能拦住。但随着接口变多、嵌套变深问题就来了函数 A 调用函数 BB 失败返回 -1A 忘记检查继续往下跑最后在 C 里段错误了。你查半天发现最早出错的地方离崩溃点隔了十几层调用。这种时候异常机制的核心价值就体现出来了——错误信息可以沿调用栈一路向上传播中间即使有代码没显式处理也不会立刻让程序陷入未定义行为而是会在某个合适的catch点被统一接管。stdexcept里的异常类本质上是一套“已分类的错误语义”。它不解决所有错误处理问题但它把最常见、最通用的一批错误类型提前替你想好了。比如函数收到一个负数半径你抛std::invalid_argument(radius must be non-negative)任何人一眼看到类型名就能明白这是参数非法。比起自定义一个MyProjectError还要在文档里解释ErrorCode::kBadArg是什么意思标准异常类的名称本身就是文档。1.2 为什么选stdexcept而不是自定义异常基类有人会问既然要抛异常为什么不统一抛std::exception或者定义一个项目自己的BaseException我的观点是std::exception太泛捕获之后你还是得靠what()字符串去区分错误类型本质上退回到了“靠约定”的路子。而自定义异常类最大的麻烦在于你需要自己处理what()返回什么字符串、怎么管理消息内存、拷贝构造函数怎么写、析构函数要不要noexcept。这些琐碎细节标准库已经帮你兜好了你继承std::runtime_error或std::logic_error之后只需要把错误消息传给构造函数即可。更重要的是标准库算法和容器在抛出异常时用的就是stdexcept这一套。比如vector::at()越界抛std::out_of_rangestoi转换失败抛std::invalid_argumentregex匹配出错抛std::regex_error它是std::runtime_error的派生类。如果你自定义一套完全不相关的异常体系就面临一个尴尬你没法在同一个catch里同时统一处理标准库的异常和自己的异常除非你在公共基类上做文章。而stdexcept的所有类都派生自std::exception这意味着你把catch (const std::exception e)写在最外层就能兜住标准库、第三方库、以及你自己遵循同一体系抛出的所有异常这是自造异常体系很难白嫖到的优势。2. 核心细节解析与实操要点stdexcept 异常家族怎么看怎么选2.1 两个分支logic_error 与 runtime_errorstdexcept头文件里一共有六张主要面孔分属两大分支。逻辑错误用std::logic_error及子类运行期错误用std::runtime_error及子类。记住这个二分法很重要因为它不是随意划分的它对应的是“理论上程序写对就不会发生”和“程序写对了也可能因为外部环境导致出错”这两种本质不同的场景。logic_error家族的成员有std::invalid_argument参数非法、std::domain_error数学域错误比如对负数开平方、std::length_error长度超出允许范围比如string::resize超过最大长度、std::out_of_range下标或迭代器越界。这一类的共同点是错误原因是程序逻辑本身的问题通常是调用方的错。如果你提供一个函数double sqrt_discriminant(double d)里面if (d 0) throw std::domain_error(negative discriminant);这就把“输入非法”这个事实非常明确地传达给了调用方。runtime_error家族的成员有std::range_error计算结果超出浮点表示范围不常用、std::overflow_error算术上溢、std::underflow_error算术下溢。这类错误的特点是代码逻辑可能完全正确但输入数据或运行环境超出了预期。比如你要解析一个外部文件里的数字文件内容被改坏了stoi抛std::invalid_argument这属于参数类问题但如果文件数值大得离谱到后面做浮点运算溢出那就是overflow_error的领土。2.2 构造函数与 what() 消息的隐藏细节每个stdexcept异常类的构造函数都接受一个const std::string或者const char*参数用于设置what()返回的消息。这里有个实际开发中容易忽略的点异常对象在抛出时会把消息字符串拷贝内部生命周期不依赖你传入字符串的存活情况。所以你可以放心传一个临时构造的std::string比如int parse_port(const std::string input) { int port 0; try { port std::stoi(input); } catch (const std::invalid_argument e) { throw std::invalid_argument(invalid port: input); } if (port 1 || port 65535) { throw std::out_of_range(port out of range: std::to_string(port)); } return port; }这里把原始输入拼进消息里是很有价值的调试习惯。很多人在现场排查问题时最恨的就是看到一句干巴巴的invalid port不知道到底是哪个端口、哪个配置文件里的值引起的。所以我的建议是what()里至少要包含三件事错误类型关键词、触发这个错误的上下文数据、以及必要的期望范围或约束信息。比如上面port out of range: 70000一眼就懂。namespace std { class invalid_argument : public logic_error { public: explicit invalid_argument(const string __arg); explicit invalid_argument(const char* __arg); }; }标准只要求构造函数存在没强制规定它必须把消息拷贝一份所以从极端严格的角度讲what()返回的指针是否一直有效取决于实现。但在所有主流标准库实现里消息都会被拷贝管理你可以安全地保留这块指针。不过我还是不建议长期保存e.what()返回的指针最好是在捕获异常后立刻把它拷贝到自己的std::string里再继续处理。实操心得异常消息里尽量避免拼接二进制数据或者大数组内容否则一旦异常路径被高频触发日志量会非常吓人。拼接关键标量值、文件名、ID 这类轻量信息就够了。2.3 捕获顺序中的切片与多态陷阱很经典的一个坑catch子句按顺序匹配先到先得。所以如果你写try { vec.at(100); } catch (const std::exception e) { std::cerr exception: e.what() \n; } catch (const std::out_of_range e) { std::cerr out of range: e.what() \n; }第二个catch永远不会执行因为std::out_of_range是std::exception的派生类会先被基类接住。正确做法是把最具体的类型写在最前面把基类写最后做兜底。这个顺序错误不会导致编译报错大多数时候只是让更具体的分支静默失效属于那种很容易留到上线的隐患。另一个与之相关的坑是异常对象的切片问题。stdexcept异常类本身没有虚析构之外的额外大对象但一旦你写出这样的代码catch (std::exception e) // 按值捕获异常对象会被切片成基类派生类型信息彻底丢失。你只能用e.what()没法再判断它到底是out_of_range还是invalid_argument。捕获异常必须用引用最好是const引用。这既是性能问题避免拷贝也是类型保持问题避免切片。这个习惯我从开始写 C 就坚持到现在已经变成肌肉记忆了。3. 实操过程与核心环节实现一套能落地到现有项目的异常处理方案3.1 五种典型场景下的异常选择速查我整理了一个平时写代码时手边会过一遍的选择清单不一定适合所有项目但覆盖面很广场景推荐异常类型典型消息格式参数为空指针、非法数值、非法枚举值std::invalid_argumentxxx must be ...数学运算超出函数定义域std::domain_errorsqrt requires x 0下标访问越界vector::at是现成例子std::out_of_rangeindex 10 out of range [0, 5)容器或字符串操作要超长扩容std::length_errorresize exceeds max_size外部数据格式错误、解析失败、IO 失败等运行期问题std::runtime_errorfailed to read config: ...数值运算溢出、除零后结果超范围std::overflow_errorinteger overflow at ...一句话记忆方式凡是调用方传参非法导致的基本往logic_error分支靠凡是环境或外部数据导致的基本往runtime_error分支靠。3.2 项目级异常处理框架中间层包装与统一日志单纯会throw和catch不算完真实项目需要一个稳定的异常处理骨架。我常用的思路是三层结构。底层是功能函数负责检查输入、执行逻辑发现问题就直接抛stdexcept。中间层是业务调用方一般在函数入口处不接异常让它自然向上传播只有当错误需要在当前层补充上下文信息比如当前操作的文件名、账号 ID时才重新包装抛出void load_user_settings(int user_id) { try { auto path build_config_path(user_id); auto content read_file(path); parse_settings(content); } catch (const std::runtime_error e) { throw std::runtime_error(failed to load user settings for user std::to_string(user_id) : e.what()); } }最上层是唯一的异常出口通常在主函数入口或者线程入口处写一个try-catch捕获std::exception记录日志返回错误码或者触发兜底逻辑。这样设计的好处是异常不会被一路打日志打出几十条重复信息而是每一层只补一条关键上下文最上方统一落盘一条完整链路。日志量可控问题定位也很快。3.3 与 RAII 结合不要在析构函数里抛异常C 的异常安全离不开 RAII但 RAII 的析构函数里有个死规矩析构函数默认不能抛异常或者至少不能让异常逃逸。std::vector的析构函数在清理元素时如果元素析构抛异常程序会直接调用std::terminate。所以你在写自己的资源管理类时~MyFile、~MyConnection内部绝对不能抛stdexcept或任何异常。那资源释放失败怎么办我的实践是释放资源时出错先记录警告日志实在不行就用一个单独的close()方法暴露给调用方让它有机会在正常执行路径中检查关闭结果并处理错误。析构函数只做“最保守的释放动作”绝对不把异常往外传。这个习惯能避免一大半神秘的崩溃问题。引用 Scott 式的经验说法就是析构函数里写throw等于把程序的命运交给了terminate。3.4 性能视角异常路径不该是主流程有些人一听到异常就害怕性能开销这很正常毕竟早年 C 异常实现确实有额外成本。但现代编译器普遍采用零成本异常模型zero-cost exception handling只要你不抛出异常正常路径上几乎没有额外开销代价都体现在异常表数据段和真正抛异常时的栈展开过程。所以性能关键路径上你可以放心用异常来报错只要保证异常事件是“罕见事件”即可。但如果你是写一个每秒调用几百万次、并且预期每次调用都会有大量非法输入的函数那这套方案可能不适合。比如一个解析指令的函数用户输入数据脏得离谱合法率只有 60%。这种情况更合理的设计是返回std::optional或错误码把异常路径当作真正的“意外事件”来用。判断标准很简单异常应该是少数情况的逃逸出口而不是主流程控制器。4. 常见问题与排查技巧实录4.1 为什么 catch 到了异常但信息是空的有朋友遇到过这种情况e.what()返回空字符串。排查步骤一般是三步。第一步确认抛出时是否传了消息第二步确认是不是某个库内部抛了一个不带消息的异常比如std::bad_alloc在某些实现下默认消息就是std::bad_alloc还好但某些第三方库可能直接throw std::runtime_error()第三步检查是不是捕获时把异常切了片但切片不会影响what()所以这步主要是排空字符串的直接原因。真正解决这个问题的方向只有一个所有throw语句必须带上有效消息并且代码评审时把“异常消息是否提供了上下文”列为检查项。4.2 noexcept 函数里异常逃逸导致的 terminateC11 之后一个函数如果被标记为noexcept它内部一旦抛出异常不会沿着调用栈找catch而是直接std::terminate。这个行为太坑了。常见的典型问题是移动构造函数有时会被隐式标成noexcept如果移动构造里抛了异常程序直接终止没有挽回余地。我在实际项目里碰到过一个问题某个类内部持有std::vectorstd::string默认生成的移动构造按规则会带noexcept但我在自定义移动构造里调了一个可能抛std::bad_alloc的函数编译器没帮我禁止运行时才炸。排查方法也很直接看到terminate调用栈先查哪些链路被noexcept约束了然后把不保险的函数上的noexcept去掉或者在其内部用try-catch包住所有可能抛异常的调用。4.3 第三方库异常与本项目异常体系的融合项目里用了很多第三方库它们抛出的标准异常类型一般能直接捕获。但有些库会抛自定义异常不继承std::exception比如某些 C 库会直接返回错误码混合线程模型下异常可能跨 DLL 边界传播出问题。面对这种情况我没法给出一个万能方案但可以分享一个稳妥思路在自己代码的边界处做一层异常转换。// 库边界转换示例 void call_third_party_api() { try { third_party::do_something(); } catch (const std::exception e) { throw std::runtime_error(std::string(third_party do_something failed: ) e.what()); } catch (...) { throw std::runtime_error(third_party do_something failed: unknown error); } }这样项目的所有上层代码只需要面对std::exception一个体系不需要为某个第三方库写一套专属 catch 逻辑。缺点是要多写一层包装代码但换来的是调用方的统一体验我认为非常值。4.4 调试技巧怎么快速找到是哪个 throw 抛出来的当异常类型对了、消息也对了但还是想立刻定位到出错的精确位置时靠日志不够快。我的习惯是在开发阶段给编译参数加-fno-omit-frame-pointer同时配合调试器在异常抛出点断住。如果使用 GDB可以用catch throw命令让程序在每一个异常抛出时自动停下再通过bt看完整调用栈。这在排查那些“消息正确但位置可疑”的异常时特别有效能省掉大半天打日志的时间。另一个小技巧是不要在what()里写自己都不懂的缩写。曾经排查一个月前的代码看到一句idx err愣是想不起来这个idx是指容器下标还是配置条目编号。后来改了规则消息里的上下文字段名必须与代码变量名保持一致比如index 100 out of range, vector size is 5这种变量名和值都出现在消息里半年后回头看你依然能瞬间理解。4.5 完整实操示例一个参数校验 文件解析的异常处理模板最后给一份可以直接抄走的模板它涵盖了本文提到的大部分要点#include iostream #include stdexcept #include fstream #include string #include vector class ConfigLoader { public: explicit ConfigLoader(const std::string path) : path_(path) {} // 对于可能出现参数错误和运行期错误的接口分别抛不同类型 std::vectorint load(); private: std::string path_; }; std::vectorint ConfigLoader::load() { if (path_.empty()) { throw std::invalid_argument(ConfigLoader: path is empty); } std::ifstream in(path_); if (!in.is_open()) { throw std::runtime_error(ConfigLoader: cannot open file: path_); } std::vectorint result; std::string line; int line_num 0; while (std::getline(in, line)) { line_num; try { int value std::stoi(line); result.push_back(value); } catch (const std::invalid_argument) { throw std::runtime_error(ConfigLoader: invalid integer at line std::to_string(line_num) : line); } catch (const std::out_of_range) { throw std::runtime_error(ConfigLoader: integer out of range at line std::to_string(line_num) : line); } } if (result.empty()) { throw std::runtime_error(ConfigLoader: no integer values found in path_); } return result; } int main() { try { ConfigLoader loader(config.txt); auto values loader.load(); for (int v : values) { std::cout v \n; } } catch (const std::invalid_argument e) { std::cerr config error: e.what() \n; return 1; } catch (const std::runtime_error e) { std::cerr runtime error: e.what() \n; return 2; } catch (const std::exception e) { std::cerr unknown exception: e.what() \n; return 3; } return 0; }注意std::stoi可能抛std::invalid_argument字符串不是数字和std::out_of_range数字超出int范围。这里我把运行期加载上下文的错误统一改写成std::runtime_error因为对上层调用方来说“配置文件某一行的数字有问题”本质上是外部数据导致的运行期错误而不是调用方传参错误。5. 让我最后再分享几点实际体会用stdexcept这几年我最大的感受是它把“错误是什么”这件事变得非常可读。以前看到return -1你得翻文档查错误码表现在看到catch (const std::out_of_range)类型本身就说明了一切。自定义异常当然有自己的价值但绝大多数项目里的错误其实都逃不出标准库这几个分类。先把这套标准玩熟再去定制项目专属异常路子会顺很多。一个很容易被忽略的后期收益是当团队的代码库里异常类型统一、消息格式规范之后日志聚合系统自动按异常类型做统计就变得非常轻松。哪个模块总抛invalid_argument、哪里频繁出现runtime_error一目了然。这比我当初靠 grep 各种错误码字符串来摸情况舒服太多。最后再交底一个小技巧如果你要在一个已经用了多年错误码的老模块里逐步引入异常不要一次性把接口全改了。先选一个出错率最高的内部函数把它的错误码改造成stdexcept异常然后在上层调用处捕获并转换成原来的错误码保持对外接口不变。这样既用上了异常的自然传播和上下文拼接又不至于让整个模块在一天内推倒重来。边角细节慢慢磨等到团队对异常行为的预期一致了再决定要不要彻底全线迁移。