C++中errc与异常的取舍：from_chars设计及未来选型建议

这是个非常接地气的问题，刚好说到了C++标准库错误处理设计里的核心权衡点——到底什么时候用异常，什么时候用错误码？咱们一步步拆解：

一、from_chars选用errc的核心动机 #

你提到的两点完全命中了标准委员会的设计思路：

• 异常的开销问题：异常抛出时需要进行栈展开、保存调用栈信息，这在高频调用的场景（比如批量解析文本中的数字）里会带来不可忽视的性能损耗。而from_chars作为C++17引入的高性能字符串-数值转换工具，就是为了替代stoi、流转换这些相对笨重的方案，用错误码（errc）直接返回错误状态，完全避免了异常的开销。
• 解析错误并非“异常情况”：在很多实际场景中，字符串无法解析成合法数值是预期内的情况——比如用户输入的格式错误、日志里的脏数据，这些都属于“正常的错误”，而非程序逻辑崩溃级的意外。用错误码处理这种情况，能让代码的逻辑更清晰：正常流程走转换成功的分支，错误流程走错误处理分支，不用把错误逻辑藏在try/catch块里。

二、对比stoi和流的设计：为什么from_chars更“现代”？ #

• stoi这类函数是C11的产物，当时标准库的异常处理理念还没完全成熟，而且它遵循了std::out_of_range这类异常的惯例——但从现代C的性能优先视角看，这种设计确实有点过时了，毕竟解析错误在很多场景里根本不是“超出预期的异常”。
• 流的设计是一种折中：它既可以通过exceptions()设置异常掩码，让解析错误时抛出携带io_errc的异常；也可以手动检查fail()、bad()等状态位。但流本身的性能就不如from_chars，而且这种双模式的设计也增加了使用的复杂度。

三、C++未来会倾向用errc替代异常吗？ #

结论是：不会完全替代，但在性能敏感、错误可预期的场景里，错误码（包括errc、std::expected这类封装）会成为优先选择。

C++标准委员会一直以来的思路是“给开发者选择的自由”，但近年来的新特性明显偏向高性能和可控性：

• C++17的from_chars/to_chars用errc返回错误；
• C++23正式引入的std::expected，把返回值和错误码打包在一起，让错误码处理更优雅，不用像单独返回errc那样需要额外的输出参数；
• 很多新的库组件（比如文件系统库的部分接口）也提供了错误码重载版本，允许开发者选择是否用异常。

但异常依然有不可替代的场景：比如内存分配失败（std::bad_alloc）、不可恢复的系统错误，这些属于真正的“异常情况”，用异常能让代码更简洁——你不用在每一次new之后都检查是否分配成功，而是把错误处理集中在catch块里。

四、你应该优先采用哪种方案？ #

给你几个明确的场景建议：

• 优先用错误码（errc/std::expected）的场景：
  • 性能敏感的高频转换场景（比如处理百万级日志、网络协议解析）；
  • 解析/序列化逻辑中，错误是预期内的（比如用户输入校验、外部数据格式校验）；
  • 嵌入式、实时系统这类禁止或限制异常使用的环境。
• 优先用异常的场景：
  • 业务逻辑层，错误属于程序逻辑错误（比如本应该是合法数值的字符串突然非法，这说明上游逻辑出问题了）；
  • 希望简化错误处理，不想在每一步转换后都手动检查错误码的场景；
  • 代码规模较小，异常带来的开销可以忽略的场景。
• 混合策略更实用：底层性能敏感模块用错误码处理，上层业务逻辑把错误码转换成异常抛出，这样既兼顾了性能，又让上层代码的可读性更好。

内容的提问来源于stack exchange，提问作者user167921