企业官网建设流程全解析

1. 先聊聊我为什么把 stdexcept 当作“项目基础设施”来重视

大概两年前，我参与维护过一套内部基础服务。那个服务跑得挺稳定，直到某天上线了一个新策略，结果线上连续出现崩溃，日志里只有一条 pallid 的 segment fault，连堆栈都被系统打乱了。我们几个开发查了半天，定位到是一个容器下标越界：某个数据分支没有走到预期逻辑，直接返回了一个错误索引。问题本身不复杂，但排查过程让人非常难受——如果当时代码里抛的是std::out_of_range，哪怕是多打一行what()日志，崩溃原因几乎是秒级可见的。

那件事之后我养成了一个习惯：不能把异常处理当成“锦上添花”的健壮性优化，它本质上是在降低线上故障的定位成本。C++ 标准库里有一个很少有人系统讲清楚、但每个项目都用得到的头文件，就是<stdexcept>。它定义了绝大多数业务代码需要的标准异常类型。你可能很早就听说过std::runtime_error，也见过std::invalid_argument，但真正能把它们用对、用得恰到好处的团队其实不多。

这篇文章我想从一个长期写 C++ 的普通开发者的视角，把我对stdexcept的理解、使用习惯、踩过的坑，以及和自定义异常搭配的方案一次性说清楚。适合刚入门的同学建立正确的异常处理观念，也适合写过一阵子 C++、但还想把自己的异常设计做得更规范的开发者。文章里的示例都是我平时写代码时真的会这么写的模式，不是教科书式地罗列 API。

先说结论：stdexcept不只是几个异常类的集合，它是一套“语义契约”。你抛什么类型的异常，别人就知道你的程序是“犯了逻辑错”还是“遇到了运行时状态不正常”。这个契约一旦确立，整个团队的代码风格、日志格式、异常处理流程都会变得整齐。

2. stdexcept 家族的语义地图：logic_error 系和 runtime_error 系到底怎么分工

<stdexcept>里定义的异常类并不是平铺的一个列表，它们像一棵树一样挂在std::exception下面。std::exception本身在<exception>里，是所有标准异常的基类，也是我们写catch (const std::exception& e)时那个统一入口。

整棵树的重点是两个分支：std::logic_error系和std::runtime_error系。这两个词是理解整个异常设计的钥匙。

logic_error这个词翻译过来是“逻辑错误”，它表达的是什么呢？是说这段代码从设计上看就存在 bug。比如函数要求参数必须大于 0，但调用方传了一个 -1，程序逻辑没有提前挡住它，这就是逻辑层面的缺陷。这类错误理论上是你自己代码的问题，修好调用方或校验逻辑就能解决。所以logic_error出现的时候，我第一反应是“去找写这段调用的人”，而不是“去重试外部系统”。

runtime_error则和现实世界打交道时发生的问题更贴近。文件不存在、网络断开、磁盘满、设备忙，这些都不是你的代码逻辑算错了，而是程序运行到某个时刻、外部环境的状态不满足要求。这类异常通常代表“这一次操作失败”，但程序整体结构没有错，往往需要上层决定要不要重试、降级，或者把错误返回给用户看。

也因为这种差异，我在一个可观测性做得比较好的项目里，经常看到团队用两个异常基类做日志分级：捕获到logic_error系就报警告，提示开发排查；捕获到runtime_error系就按实际错误码和重试策略处理。这种做法听着简单，实际上非常有效，因为把错误分类这件事前置到了抛出点。

stdexcept中每个类构造时都接受一条消息，可以是const char*，也可以是std::string。如果你需要把变量拼进去，std::string版本配合字符串拼接是日常最常用的写法：

#include <stdexcept> #include <string> void connect(const std::string& host, int port) { if (host.empty()) { throw std::invalid_argument("host must not be empty"); } if (port < 1 || port > 65535) { throw std::invalid_argument("invalid port: " + std::to_string(port)); } }

这里我会特别提醒一件事：构造异常对象时临时拼出来的std::string，千万不要担心它析构了怎么办。标准库异常类内部会保存一份消息副本，what()返回的是这个副本的指针，不会因为临时对象销毁而失效。但这一点只对标准库异常成立，后面讲自定义异常时我会再提。

length_error在纯业务代码里并不常见，但涉及容器和序列化时它很关键。比如你写一个二进制协议解析器，对方传入的长度声称有 10GB，而你的缓冲区上限只有 1GB，此时抛出std::length_error("message length exceeds upper bound")就比抛一个笼统的runtime_error更贴切。因为它告诉调用者：问题出在长度约束上，不是网络也不是参数类型。

out_of_range最有名的触发点是容器的at()函数。std::vector::at(5)和std::vector::operator[](5)的区别是前者会检查越界并抛出out_of_range，后者是未定义行为。我在代码评审里见过不少人写了一堆自定义判定最后抛个std::exception，其实直接用at()配合捕获，既准确又省代码。

domain_error和invalid_argument的区别容易让人迷糊。我给一个记忆方法：invalid_argument说的是“这个参数长得就不该出现在这里”，比如字符串格式不对、端口不是数字；而domain_error说的是“参数类型对，但超出了值域”，比如角度值要求范围是[-1, 1]，你传了 3。实际很多项目只用invalid_argument一种就够，但如果你在做数值计算、图形学、科学计算库，domain_error能让下游代码更精确地判断问题来源。

overflow_error和underflow_error在实际项目中反而没有名字看起来那么常用，因为 C++ 整型溢出通常是静默发生的，并不会自动抛异常。你往往需要自己检测后主动抛出：

#include <limits> #include <stdexcept> int checked_add(int a, int b) { if (a > 0 && b > std::numeric_limits<int>::max() - a) { throw std::overflow_error("integer overflow in checked_add"); } return a + b; }

range_error也是同理，它描述“计算结果超出了合理范围”。比如你计算了一个百分比的聚合值，结果是 0 到 100 之外，此时抛range_error是很有表达力的。总体来看，runtime_error系的几个类更贴近系统底层和数值计算，写业务服务的人碰到runtime_error本身的次数会远多于它的三个子类。

3. 从抛出到捕获的完整链路：类型、顺序、对象生命周期都要照顾到

异常真正容易出问题的地方，往往不在“抛”而在“接”。很多人一开始只知道写try和catch，但写出来的代码能跑，却会在特定场景下丢掉关键信息，甚至让纠错方向彻底跑偏。我挑三个最典型的细节展开。

3.1 按值抛、按引用接，别按指针也别按值

正确写法是：

try { throw std::invalid_argument("bad input"); } catch (const std::invalid_argument& e) { std::cerr << e.what() << '\n'; }

为什么必须按引用？如果按值捕获，会发生对象切割。考虑这种情况：

class MyError : public std::runtime_error { public: MyError(const std::string& msg, int code) : std::runtime_error(msg), code_(code) {} int code() const noexcept { return code_; } private: int code_; }; try { throw MyError("something failed", 42); } catch (std::runtime_error e) { // 错误示范 // e.code() 不存在，MyError 的扩展信息全部丢失 }

按值接收时，异常对象会被切割成std::runtime_error，派生类的字段、覆盖过的接口全部没了。虽然 C++ 异常机制本身保证按值捕获也能正确匹配，不会出现悬空引用，但丢信息这件事已经违背了抛出派生异常的初衷。所以我的习惯非常简单：一律catch (const 某个类型& e)。

按指针捕获则更危险。throw new std::runtime_error(...)这种写法意味着谁捕获谁就要负责delete，而一旦在半路被别的catch提前接走，内存就泄漏了。现代 C++ 项目里没有理由用指针做异常传递。

3.2 捕获顺序是“先具体后通用”

catch子句按出现顺序从上到下匹配，第一个能匹配的就会执行。因此如果先写catch (const std::exception& e)，后面再写catch (const std::invalid_argument& e)，后面的分支永远不会执行。

一个反面案例：

try { // 一些可能抛出多种异常的调用 } catch (const std::exception& e) { // 统一处理 } catch (const std::invalid_argument& e) { // 永远走不到 }

正确顺序是从最具体的异常开始，逐步放宽：

try { parseConfig(configText); connect(host, port); } catch (const std::invalid_argument& e) { // 参数错误，提示用户修正配置 } catch (const std::out_of_range& e) { // 配置项越界，单独处理 } catch (const std::runtime_error& e) { // 运行时失败，走重试或降级逻辑 } catch (const std::exception& e) { // 完全未知的 C++ 异常，记录日志 } catch (...) { // 非 C++ 异常，比如 Windows SEH 或非法抛掷 }

我见过不少代码把所有异常都统一接成std::exception，然后打印一个what()就结束了。这当然比崩溃好，但它丢失了分类处理的空间。如果团队成员都知道自己的异常会触发哪一层处理，整个系统的反馈链路会清晰非常多。

catch (...)这种“兜底”也不是不能写，但要注意两点：第一，它是最后一道防线，不是第一选择；第二，如果你在catch (...)里既打不出错误信息，也不知道异常对象是什么，那还不如不抓，让它直接终止进程。在服务型程序里，未捕获异常通常会导致程序崩溃退出，这能让你通过退出码、崩溃转储来定位问题。除非你确实需要防止一个任务线程因为异常退出导致整个进程终止，否则不要随手加一个空catch。

3.3 重新抛出不丢失原始异常

一个很常见的需求是“先记录日志，再让上层继续处理”。有人会在catch里把异常对象再throw e;，这会重新生成一个新的异常对象，如果e是基类引用并且实际是个派生类，这个过程同样会切割信息。正确做法是用不带对象的throw;：

try { process(task); } catch (const std::exception& e) { logError("task failed: " + std::string(e.what())); throw; // 重新抛出原始异常 }

这个细节我在实际项目里反复强调过。特别是你做中间件、做基础库的时候，底层函数抛出一个MyNetworkError，上层函数负责记录一条带上下文的日志，同时希望最顶层还能捕获到原始的MyNetworkError对象，那么throw;是唯一正确选择。

关于what()的生命周期，前面已经提到标准库内部会保存消息字符串。但对于自定义异常，如果某天你图省事，写了一个只存const char*的异常类，而那个指针指向的是一个局部std::string的内存，随着局部变量析构，what()就变成悬空指针了。后面写自定义异常时，我建议仍然把消息交给std::runtime_error的构造函数管理，不要自己去省那一次拷贝。

最后补充一个容易忽略的点：在catch (const std::exception& e)里，把e.what()转成std::string再继续拼接日志是最安全的，因为what()返回的const char*在极端情况下可能是nullptr，直接做字符串流输出有风险。写成std::string(e.what() == nullptr ? "unknown" : e.what())虽然啰嗦，但在长期运行的守护进程里很值得。

4. 自定义异常何时出场：继承标准异常类还是自己派生基类

标题是“C++使用stdexcept”，但实际项目里几乎不可能只用那八个标准类。业务系统一定有自己的领域异常，比如“订单状态不匹配”“用户权限不足”“上游服务返回错误码”。那这些自定义异常和stdexcept是什么关系？

我的核心观点是：只要你的自定义异常在本质上属于“某一步操作失败了”或“某个参数/逻辑错了”，就应该从std::runtime_error或std::logic_error派生，而不是从std::exception裸派生。因为从runtime_error派生，你和标准库就有了共同的契约：外部代码只要catch (const std::exception& e)就能像处理标准异常一样打印what()；而你自己的派生子类可以携带更多信息。如果全员都从裸std::exception派生，你连“这是逻辑错还是运行错”都无法快速区分。

我常用的自定义异常模板是这样的：

#include <stdexcept> #include <string> class NetworkError : public std::runtime_error { public: NetworkError(const std::string& message, int code) : std::runtime_error(message), code_(code) {} int code() const noexcept { return code_; } private: int code_; };

这样设计有两个好处：异常展示层只需要统一处理std::exception，能自动拿到what()；需要专门处理网络错误的业务层则可以catch (const NetworkError& e)并读取code_。

如果你需要的不只是错误码，而是一整条错误链，我建议异常类里存“上下文信息”而不是“完整堆栈”。很多新人在自定义异常里放一个std::stacktrace或一个巨大的字符串，结果异常对象本身非常庞大，抛异常的时间开销也显著上升。更合理的做法是异常只记录关键字段，例如订单号、接口名、错误码，然后把完整堆栈交给日志系统在全局兜底处统一打印。

再复杂一点的情况，可以使用std::system_error配合std::error_code。std::system_error本身也继承自std::runtime_error，它专门用来表达“系统调用失败”。如果你开发底层库，比如文件系统操作、网络 socket 封装，用std::system_error比自定义一个普通异常更标准，因为error_code可以和系统的errno、平台错误码对接：

#include <system_error> #include <cerrno> void readFile(const std::string& path) { FILE* f = std::fopen(path.c_str(), "r"); if (!f) { throw std::system_error(errno, std::generic_category(), "failed to open " + path); } }

我个人的选择标准是：面向业务逻辑的模块，优先用从runtime_error派生的自定义异常；面向操作系统和第三方库的薄封装层，优先用std::system_error。这两者并不冲突，业务层捕获到std::system_error后也可以再包装成业务异常向上抛。

自定义异常还有一个容易让新手忽略的点：异常类的析构函数不要声明成noexcept(false)，也不要在析构里做任何可能抛异常的操作。析构函数默认是noexcept的，在栈展开过程中析构如果再次抛异常，会直接调用std::terminate杀死整个进程。如果确实需要在异常清理阶段释放资源，那就老老实实用 RAII 对象，让成员的析构函数去完成释放，不要在自定义异常的析构函数里写复杂逻辑。

关于所谓“空异常类”，也就是只改个类名、不增加任何字段的派生类，它有没有价值？我觉得有。比如：

class ConfigParseError : public std::runtime_error { public: using std::runtime_error::runtime_error; };

它虽然没有新增成员，但类型本身就能表达领域概念。上层catch (const ConfigParseError& e)一眼就能看出是配置解析阶段出了问题。这类异常不增加任何开销，却让代码意图清晰很多，我非常推荐在分层架构中使用。

5. 落进团队实践的三个经验：日志、跨模块边界、性能误区

前面讲了很多语法层面的东西，但一个东西真正能发挥价值，还要靠团队怎么定规矩。我参与过的项目里，异常这部分的成熟度差异非常大，这里分享三条经验。

5.1 日志要记录的是“上下文”，不只是 what()

很多人在全局兜底捕获里打印e.what()，但一条孤零零的“invalid port”并没法快速定位问题。你需要把当时的关键上下文拼进去。做法有两种：一是在抛出前就拼好std::string消息，二是捕获时把上下文追加到日志里。我推荐前者，因为消息跟着异常对象走，无论在哪个层级被捕获，这条消息都有完整信息。

throw std::invalid_argument( "invalid port=" + std::to_string(port) + ", host=" + host + ", expected range: [1, 65535]");

消息有点长没关系，日志系统会自动聚合。但要注意不要塞敏感信息，避免把密钥、令牌之类的拼进异常消息。这条我从实战教训里得出的建议特别管用：线上排查问题时，信息完整度直接决定了定位速度。

5.2 跨动态库边界时统一转译，不要让异常在模块边界“裸奔”

C++ 异常能不能跨动态库抛出，取决于动态库和主程序是否使用同一套运行时、异常处理模型是否兼容。在 Windows 和 Linux 上细节不同，但结论对你是一样的：不要依赖异常跨模块边界传播。

实际项目里我常用的模式是模块内部可以用异常，到了模块导出函数的最外层全部捕获，转成错误码或结果对象：

extern "C" int module_process(const char* input, char* out, int outLen) { try { // 内部可能抛出各种异常 return processInternal(input, out, outLen); } catch (const std::exception& e) { logError(e.what()); return ERROR_INTERNAL_FAILURE; } catch (...) { logError("unknown exception"); return ERROR_UNKNOWN; } }

很多同学觉得这种写法“不够 C++”，但我认为这是工程上的诚实：底层库的调用者未必想被你逼着处理异常，尤其是用 C 接口接入大型系统时。内部一套现代 C++ 风格，边界一层统一转译，既享受了异常带来的表达力，又避免了不同编译单元之间异常处理模型不一致带来的崩溃风险。

5.3 异常的性能开销只在抛出时发生，但别拿异常当控制流

这是一个流传很广的说法：现代 C++ 的异常在零成本模型下，正常路径没有额外开销，真正昂贵的是抛出和栈展开过程。所以如果你把异常当成“循环里的普通分支判断”来用，性能会快速恶化。比如：

for (int i = 0; i < 100000; ++i) { try { if (isValid(i)) { throw std::runtime_error("stop"); } } catch (...) { break; } }

这纯属反面教材。异常应该用于“不可控的错误路径”，而不是常规逻辑控制。如果一段代码在程序正常运行中会被反复触发很多次，那就该用if和返回值，不要去抛异常。正确姿势是把“可预期失败”和“意外失败”分成两条路：前者用错误码或可选值，后者用异常。

noexcept也是我在团队规范里明确要求的一个点。移动构造函数、swap、析构函数如果确实不会抛异常，就标注noexcept。标准库容器在扩容时，会依据移动构造函数是否noexcept来决定选用移动还是拷贝策略。这个细节平时很难察觉，但一旦你写了一个不该标noexcept却标了的移动构造函数，异常发生时程序会直接terminate，比错误返回更隐蔽。

最后再分享一个我在实践中反复验证过的习惯：异常消息统一用英文。不是说中文不能写，而是日志系统、外部监控、第三方排查人员对英文消息的兼容性更好；而且有些系统的默认字符集不是 UTF-8，中文字符拼进异常消息后日志会乱码。当然这只是我的个人经验，团队如果确定全链路都吃 UTF-8，那用中文也无妨。

写在最后的个人体会

stdexcept这个东西看起来轻量，甚至有些人觉得“不就是几个异常类名嘛”。但它实际上定义了一个项目错误处理的地基。选择从哪个异常类派生、怎么拼消息、在哪一层捕获、哪些边界不让异常穿过，这些决定都会直接影响你半年后排查线上事故的效率。

我自己踩过最深的一次坑，是因为自定义异常没有继承std::exception，而是一个完全不相关的基类，结果所有集中兜底的catch (const std::exception& e)都接不到这种错误，线上日志里只有一堆“unknown exception”。从那之后，我把“派生异常必须挂在std::exception系下”写进了项目规范里。

如果你现在刚接触 C++ 异常，我建议从今天开始做一件事：把代码里那些throw std::string("...")或者throw 1的写法全部清掉，换成stdexcept里语义最贴合的类型；然后动手写一个继承自std::runtime_error的业务异常基类，把错误码和消息统一起来。等这套基础打好了，你会发现异常并不是什么玄学，它只是一套让你和团队沟通错误时更有默契的语言。