在C++框架开发里，错误处理并不是只有抛出std::exception一种写法。不同框架因为性能敏感度和易用性要求不同，往往会采用差异很大的异常处理机制。常见的类型包括传统返回值错误码、标准异常体系，以及两者结合的混合模式。本文从原理、代码形态和适用场景三个角度，对它们做系统比较。
一、基于返回值的错误码机制
返回值错误码是最早期的C++框架普遍采用的方案。函数通过返回整型或枚举表示成功或失败，调用方必须主动检查。这种机制没有运行时的栈展开过程，错误传递的开销极低，在高频调用的底层模块中非常稳定。
它的主要问题是代码可读性下降。每一个可能失败的函数调用后都要写判断分支，业务逻辑被错误处理淹没。另外，错误码容易被忽略，如果调用方不检查返回值，缺陷会潜伏到很晚才暴露。
#include <iostream>
enum class ErrCode {
Ok = 0,
NullPtr,
OutOfMemory
};
ErrCode create_buffer(int size, char*& buf) {
if (size <= 0) return ErrCode::NullPtr;
buf = new (std::nothrow) char[size];
if (!buf) return ErrCode::OutOfMemory;
return ErrCode::Ok;
}
int main() {
char* p = nullptr;
ErrCode rc = create_buffer(1024, p);
if (rc != ErrCode::Ok) {
std::cout << "failed" << std::endl;
return 1;
}
// 使用 p
delete[] p;
return 0;
}
优点与缺点分析
从性能角度看，错误码几乎零成本，不会触发任何隐式控制流跳转。在操作系统内核、嵌入式框架或者交易系统低延迟路径中，这是首选。
缺点是接口契约变弱。调用者必须知道该函数可能返回哪些码，并且人工保证检查。大型框架里若缺乏规范，错误码含义还会随着模块演化而冲突，增加维护负担。
二、标准异常机制
C++标准异常利用try、catch和throw完成控制流转移。当异常抛出时，运行时会沿调用栈展开，依次调用局部对象的析构函数，从而保证资源不泄漏。这对编写安全的框架接口非常友好。
异常机制把正常逻辑和错误逻辑分离，代码更清晰。但它不是免费的：抛出异常涉及栈展开、类型匹配和可能的内存分配，在出错频繁的路径上可能让吞吐明显下降。
#include <stdexcept>
#include <string>
void process(int value) {
if (value < 0) {
throw std::invalid_argument("value must be non-negative");
}
// 正常处理
}
int main() {
try {
process(-1);
} catch (const std::exception& e) {
// 处理异常
}
return 0;
}
适用边界
标准异常适合错误发生频率低、但错误处理链较深的场景，比如框架的初始化、配置加载或跨模块的公共接口。这样既能减少调用方的分支，又不会在性能热路径上付出代价。
需要注意的是，很多实时系统或游戏引擎明确禁用异常，因为栈展开的时间不可预测。这类框架会在编译期用-fno-exceptions关闭标准异常支持。
三、混合模式
混合模式在现实中的大型C++框架里最常见。核心思路是：内部高性能模块用错误码，避免异常开销；对外暴露的API用异常，给上层语言或脚本绑定提供统一的安全接口。
这种分层设计兼顾了效率和易用性。内部模块保持可控的低成本，外部调用者不必记住每个错误码。转换层负责把错误码翻译成异常，或者反之。
#include <stdexcept>
enum class InternalErr { Ok = 0, Fail };
InternalErr inner_compute() {
return InternalErr::Fail;
}
void public_api() {
InternalErr e = inner_compute();
if (e != InternalErr::Ok) {
throw std::runtime_error("inner computation failed");
}
}
设计权衡
混合模式要求团队对模块边界有清晰认知。如果随意在内部抛异常，性能优势会丧失；如果对外只返回错误码，集成方体验会变差。框架文档应明确标注哪些接口可能抛异常。
此外，转换层本身要足够薄，避免成为瓶颈。一些框架用宏统一错误码到异常的映射，降低重复代码。
四、机制比较总结
下表从几个维度对三种机制做直观对比：
| 机制类型 | 运行时开销 | 代码清晰度 | 资源安全 | 典型场景 |
|---|---|---|---|---|
| 错误码 | 极低 | 较低 | 依赖人工 | 底层循环、内核 |
| 标准异常 | 高（异常路径） | 高 | 自动保证 | 初始化、API边界 |
| 混合模式 | 可控 | 中等 | 分层保证 | 大型框架 |
选择异常处理机制时，应先画出框架的性能剖面，标记热路径与冷路径。热路径坚持错误码，冷路径放心用异常，中间用薄转换层连接，是多数成熟C++框架的务实做法。
没有绝对优秀的异常机制，只有契合框架性能目标与维护模型的机制。
五、实践建议
在新建C++框架时，建议先约定错误传递规范，而不是等到模块膨胀后再统一。规范里写清：哪些命名空间内部禁用异常，哪些公共头文件允许抛出哪些异常类型。
同时，配合静态分析工具检查未处理的错误码返回值，可以防止人为疏忽。对于异常，确保编译选项和第三方依赖的异常设置一致，避免跨边界对象析构出错。