在C++生态中，标准语言层面只给出了异常（exception）和错误码（error code）两种基础手段，但各类成熟的C++框架为了兼顾性能、跨平台能力和易用性，往往在其之上封装了更丰富的错误处理机制。认识这些机制，有助于我们在集成框架时快速定位问题，也能让我们自己设计的模块更加健壮。
一、基于异常的机制
异常是C++框架中最常见的严重错误处理方式。当框架遇到无法在当前函数内恢复的错误，例如内存分配失败、文件无法打开或网络连接断开，就会抛出派生自std::exception的对象。调用方通过try-catch块捕获并处理，避免程序直接崩溃。
以Boost库为例，它大量使用boost::system::system_error，该异常内部携带了错误码和错误信息。这种设计让异常既能沿着调用栈向上传递，又保留了底层系统的错误细节。下面是一段演示代码：
#include <boost/asio.hpp>
#include <iostream>
int main() {
try {
boost::asio::io_context io;
// 尝试连接一个无效地址，会抛出system_error
boost::asio::ip::tcp::socket sock(io);
boost::asio::ip::tcp::endpoint ep(
boost::asio::ip::make_address("192.168.0.1"), 9999);
sock.connect(ep);
} catch (const boost::system::system_error& e) {
std::cerr << "捕获框架异常: " << e.what() << std::endl;
}
return 0;
}
异常机制的优点在于错误传播路径清晰，不用在每个函数返回处写判断逻辑。但缺点是会带来一定的运行时开销，并且在析构函数中抛异常可能导致程序终止，因此框架通常要求用户不要在析构函数里向外抛异常。
另外，像Qt这样的框架虽然也支持标准异常，但在信号槽调用中默认不跨线程抛异常，而是将错误转化为事件或返回错误对象，这是为了避免在事件循环里出现未捕获异常而直接结束进程。
二、错误码与返回值机制
很多注重性能的C++框架倾向于使用错误码而非异常。函数正常执行时返回有效结果，出错时通过返回值或输出参数给出错误码。调用方必须主动检查，否则错误会被静默忽略。
例如POCO库的网络模块就广泛采用返回int或Poco::ErrorCode的方式。下面示例展示了一个简单的文件读取接口如何返回错误码：
#include <Poco/File.h>
#include <iostream>
int read_config() {
Poco::File f("config.ini");
if (!f.exists()) {
return -1; // 文件不存在错误码
}
// 其他读取逻辑
return 0;
}
int main() {
int rc = read_config();
if (rc != 0) {
std::cout << "读取配置失败，错误码: " << rc << std::endl;
}
}
错误码机制的性能开销极低，适合高频调用的底层接口。但它的弊端也很明显：代码里会充斥大量if (rc != 0)判断，一旦遗漏检查，bug将难以排查。因此一些框架会同时提供异常版本和错误码版本供选择。
ACE框架是另一个典型，它的多数方法都返回-1表示失败，并通过ACE_OS::last_error()获取具体原因。这种类POSIX的风格让熟悉系统编程的开发者容易上手，但也要求团队有严格的代码规范来保证错误不被漏判。
三、断言与调试期检查
除了运行期的异常和错误码，C++框架通常还内置断言（assert）来捕捉开发阶段的内部逻辑错误。断言在发布版本中往往被禁用，因此不会影响性能，但能在测试阶段暴露空指针、越界访问等问题。
Qt提供的Q_ASSERT和Q_CHECK_PTR就是这类工具。当传入空指针时，框架会在调试输出中报告错误并中断程序，提醒开发者修正逻辑。示例如下：
#include <QWidget>
#include <Q_ASSERT>
void update_ui(QWidget* w) {
Q_CHECK_PTR(w); // 若w为nullptr，调试版会触发断言
w->update();
}
断言的价值在于把“不该发生”的条件提前暴露，而不是等到线上崩溃。但它不能用于处理用户输入或外部环境导致的可预期错误，否则发布后这些保护就会消失。因此断言常与错误码配合使用：断言防内部bug，错误码防外部异常。
一些框架还会提供自定义的验证宏，比如Boost.Contract用于前置条件和后置条件检查，这相当于把断言扩展成了契约式设计，进一步提升代码可靠性。
四、日志与回调通知机制
现代C++框架普遍集成了日志系统，把错误以分级（debug、info、warning、error）方式记录下来。同时，它们允许注册错误回调，当框架内部出错时主动通知业务层，而不是被动等调用方发现。
例如folly库可以通过folly::Singleton的错误处理钩子，在单例构造失败时调用用户设定的函数。下面是一段简化示例：
#include <folly/Singleton.h>
#include <iostream>
struct MyService {
MyService() { throw std::runtime_error("init fail"); }
};
folly::Singleton<MyService> g_service([] {
std::cerr << "单例创建失败回调" << std::endl;
return std::make_unique<MyService>();
});
int main() {
try {
g_service.try_get();
} catch (...) {
// 已被回调记录
}
}
日志加回调的组合让错误处理从“同步返回”变成了“异步可观测”，对服务端程序尤其重要。运维人员可以通过错误日志快速定位故障，而业务代码不用在每个调用点写错误处理，降低了耦合。
不过这种机制要求团队约定好日志格式和告警阈值，否则海量warning反而会掩盖真正的error。框架一般提供配置接口来调整日志级别和输出目标，比如输出到文件或网络收集系统。
五、总结与选型建议
综合来看，C++框架提供的错误处理机制主要包括：异常传递严重故障、错误码表达可恢复问题、断言拦截开发期逻辑错误、日志与回调实现异步可观测。它们在不同的性能与安全性权衡下被组合使用。
在实际项目中，如果写的是底层高频库，建议以错误码为主、异常可选；如果是应用层业务，多用异常配合框架日志能减少样板代码。断言则应始终开启在测试环境，作为质量防线。理解框架文档里对应的章节，才能把错误真正管起来，而不是让它在调用链里悄悄流失。