C++面向对象程序怎么统一处理跨模块错误-C++-PHP中文网

应使用继承std::exception的自定义异常类+统一catch块，因errno线程不安全、易被覆盖，返回码无法携带上下文且易被忽略；而异常可跨模块传递丰富错误信息，确保错误不丢失、可追溯、易处理。

c++面向对象程序怎么统一处理跨模块错误

用继承 std::exception 的自定义异常类 + 统一 catch 块，而不是靠返回码或全局错误变量。

为什么不能用 errno 或返回码跨模块传错

errno 是线程局部但非异常安全的：多个函数连续调用时，中间某步覆盖了 errno，上游就拿不到原始错误；返回码（如 int）无法携带上下文（文件名、行号、参数值），且容易被忽略或误判。模块 A 抛出 std::runtime_error("DB connect failed")，模块 B 却只检查 if (ret != 0)，信息断层就发生了。

常见错误现象：errno 在多线程中读取为 0，但实际操作已失败；C 风格接口混入 C++ 模块后，try 块捕不到 errno 变化；日志里只看到 “error -1”，查不出是哪个 SQL 语句超时。

每个模块都应把底层错误（如系统调用失败、SQL 错误码）立即转为异常对象，不“暂存”
禁止在公共头文件中暴露 errno 或裸整型错误码作为接口契约
若必须兼容 C 接口（如回调函数），用 extern "C" 封装一层，内部仍走异常转换

怎么设计可跨模块传递的异常类型

关键不是“多继承”或“模板化”，而是让所有模块都链接到同一份异常基类定义，并确保 what() 返回稳定字符串（不含栈变量引用）。标准库异常（如 std::runtime_error）能跨 DLL/SO，但不带业务上下文；自定义类必须满足：析构函数 noexcept、拷贝构造可访问、不依赖模块私有符号。

推荐结构：

C++ Code Review Master

组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。

下载

class AppError : public std::exception {
    std::string msg_;
    int code_;
public:
    AppError(int c, const char* msg) : msg_(msg), code_(c) {}
    const char* what() const noexcept override { return msg_.c_str(); }
    int code() const noexcept { return code_; }
};

所有模块包含同一份 AppError.h（不要各写一个同名类）
避免在 what() 中拼接 std::to_string 或调用虚函数——可能触发新异常
若需堆栈追踪，用 std::current_exception() + std::rethrow_exception() 向上透传，而非在 catch 里重新 throw 新对象

统一捕获点该放在哪一层

不是在每个函数入口加 try/catch，而是在模块边界（如 API 入口、线程主循环、事件处理器）设唯一 catch 块。例如网络模块的 handle_request()、GUI 模块的 on_button_click()、服务主循环的 while (running) { ... }。

错误做法：在工具函数 read_config() 里自己 catch 并 log，然后返回默认值——这等于吞掉错误，上层永远不知道配置缺失。

只在“能做决策”的位置捕获：比如能弹窗提示用户、能切换降级策略、能记录完整上下文并退出进程
跨模块调用链中，中间层函数（如 Service::process()）只负责抛出或转换异常，不处理
最终 catch 块应统一调用日志器（带 __FILE__、__LINE__、线程 ID），再决定是否终止进程

动态库/插件场景下的异常传递风险

Windows 上 DLL 和主程序若用不同 CRT（如 /MDd vs /MT），throw 跨 DLL 边界会直接 crash；Linux SO 一般没问题，但若插件和宿主编译选项不一致（如一个开 -fno-exceptions），catch 会失效。

最稳妥的做法：插件接口全部用 C 风格（extern "C"），错误通过输出参数 int* error_code 传出，内部仍用 C++ 异常做开发期保护；发布前用静态分析工具（如 clang++ -fsanitize=undefined）验证异常传播路径。

容易被忽略的一点：即使你写了完美的异常类，只要某个模块的析构函数里抛了异常（比如 ~Connection() 调 close() 失败），整个程序就会调用 std::terminate() —— 因为析构函数默认是 noexcept。所以，跨模块资源管理必须用 RAII，且所有析构逻辑必须不抛异常。

C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！