C++如何实现带上下文的错误报告？（嵌套异常或error_code）

错误处理从来都不只是返回一个错误码或者抛出一个字符串。真实业务里，错误往往跨越多个函数调用层、多个模块边界，如果每个函数只报告自己看到的表层现象，排查时就得像考古一样在日志里扒拉。C++需要一种机制，既能记录错误发生的精确位置，又能把调用链上的业务上下文（比如“正在加载玩家存档”）一层一层叠加上去，最后形成一条完整的错误报告链路。

嵌套异常：自动编织错误链

从C++11开始，标准库在之外新增了嵌套异常的支持。核心组件包括std::nested_exception基类、std::throw_with_nested函数以及std::rethrow_if_nested。它们的用法非常直接：在捕获异常后，如果你想附加上下文再重新抛出，只需将当前异常“嵌套”进一个新异常里。

假设底层有一个读取配置的函数，它可能抛出std::runtime_error("Config file not found")。在更上层的业务逻辑里，我们捕获它，然后添加当前业务上下文：

void load_player_data(const std::string& player_id) {
    try {
        // 底层可能抛出各种异常
        load_config("game.cfg");
    } catch (...) {
        // 捕获一切，附加当前上下文后重新抛出
        std::throw_with_nested(std::runtime_error("Failed to load player data for " + player_id));
    }
}

外部调用栈更上层的代码捕获load_player_data抛出的异常后，可以通过递归解包的方式打印完整链条。std::rethrow_if_nested会检查当前异常是否包含嵌套对象，如果有则抛出内部异常，这正好适合放在catch块中递归使用：

void print_exception(const std::exception& e, int level = 0) {
    std::cerr << std::string(level, ' ') << "exception: " << e.what() << std::endl;
    try {
        std::rethrow_if_nested(e); // 如果内部有嵌套异常，会重新抛出
    } catch (const std::exception& nested) {
        print_exception(nested, level + 1);
    } catch (...) {
        std::cerr << std::string(level + 1, ' ') << "unknown nested exception" << std::endl;
    }
}

最终输出会从最外层一直显示到最初底层的异常，清晰地还原“加载玩家数据时出错，因为加载游戏配置时出错，因为配置文件没找到”这样的完整故事。相比手动拼接what()字符串，嵌套异常的最大优势是类型安全和信息不丢失——底层异常的类型、消息都原封不动地保留着，上层完全可以按派生类型进行过滤或恢复处理。

不过需要注意的是，std::throw_with_nested只在当前catch块内有效，因为它依赖当前正在处理的异常对象。如果离开catch范围之后才试图嵌套，会导致未定义行为。另外，嵌套异常对象内部使用std::exception_ptr存储原异常，这涉及到引用计数的控制块分配，存在极小的时间开销，但对绝大多数应用来说完全可以忽略。

error_code：非异常的上下文携带者

有些代码库禁止或限制异常使用，例如嵌入式环境、实时系统或对二进制大小极端敏感的项目。此时std::error_code（C++11引入）成为传递错误上下文的理想选择。它本身是一个简单的值对象，内部包含一个整型错误值和一个指向std::error_category的指针，后者提供了错误消息、名称以及等价比较的功能。

标准库已经预定义了std::generic_category()和std::system_category()，分别对应POSIX错误码和操作系统相关错误码。但真正构建上下文能力的地方在于自定义错误类别。我们可以为某个模块定义一个error_category单例，并注册一系列特定的错误码：

enum class player_errc {
    invalid_id = 1,
    save_file_corrupted,
    profile_too_large
};

class player_error_category : public std::error_category {
public:
    const char* name() const noexcept override { return "player"; }
    std::string message(int ev) const override {
        switch (static_cast<player_errc>(ev)) {
            case player_errc::invalid_id: return "Player ID is invalid";
            case player_errc::save_file_corrupted: return "Save file corrupted";
            case player_errc::profile_too_large: return "Player profile exceeds size limit";
            default: return "unknown player error";
        }
    }
};

const std::error_category& player_category() {
    static player_error_category instance;
    return instance;
}

之后函数就可以返回std::error_code或将其通过输出参数传递。上下文信息可以通过组合多个error_code的方式实现，但标准库并没有内置类似嵌套异常那样的自动链式结构。实践中常见的做法是让上层函数在检测到底层的error_code后，生成一个新的错误码，并在日志或消息中手动附加上下文：

std::error_code load_player(const std::string& id) {
    std::error_code ec = load_save_file(id);
    if (ec) {
        std::cerr << "loading player " << id << " failed due to: " << ec.message() << std::endl;
        return make_error_code(player_errc::save_file_corrupted);
    }
    return {};
}

这样虽然不是自动的嵌套，但通过上层函数显式打印或记录底层的ec.message()，同样可以达到上下文叠加的效果。相比于异常，error_code的另一个优点是调用方必须显式检查错误，消除了异常被悄然忽略的风险，不过这也带来了代码侵入性强、容易忘记传播的问题。

需要说明的是，std::error_code自身不携带调用栈或源文件行号等详细信息。如果想附着这类上下文，可以配合自定义的error_info结构体，并使用std::error_condition或线程局部存储来记录额外信息。不过这种手动管理容易出现遗漏，社区里也有不少增强版的错误处理库（例如boost.outcome）用类型安全的result<T>来包装error_code并携带更多元数据。

混合策略：让异常携带error_code

完全隔离异常和error_code并不总是最优解。很多时候我们希望内部使用error_code来传递错误（因为底层库就是那样设计的），而在业务层却偏好用异常统一处理所有失败。此时可以让异常类持有一个std::error_code成员，这样既保留了异常栈解绕带来的便利，又保留了精确的错误分类能力。

class error_with_context : public std::runtime_error {
    std::error_code ec_;
public:
    error_with_context(std::error_code ec, const std::string& context)
        : std::runtime_error(context + ": " + ec.message()), ec_(ec) {}
    
    const std::error_code& code() const noexcept { return ec_; }
};

void perform_operation() {
    std::error_code ec = low_level_io();
    if (ec) {
        throw error_with_context(ec, "I/O failed during network handshake");
    }
}

上层在捕获error_with_context后，可以根据code()返回的std::error_code进行精确的比较和条件分支，例如区分是超时、权限拒绝还是资源耗尽，同时又能从what()中得到完整的人类可读上下文。进一步还可以结合嵌套异常，把这种携带错误码的异常放入嵌套链中，使得最终的错误报告既有业务上下文层级，又有可编程的错误码标识。

混合策略的另一个思路是采用类似std::optional<std::error_code>或outcome::result这样的类型，让函数返回值同时包含成功数据或错误信息，并在边界处转换为异常。这种设计在需要高性能冷静路径的应用中很流行：内部始终用值语义传播错误，等到了最适合统一处理异常的那一层（比如任务调度器），再转换成异常抛出，从而减少异常机制带来的开销。

无论选择哪种混合策略，设计时最重要的是明确一个原则：错误信息在每一层只能增加，不能减少。底层详细的错误码和消息是诊断的黄金线索，无论经过多少层装饰，最终被呈现出来时应当完整还原从发生点到捕获点的全景。这才是带上下文的错误报告要达到的核心目的。

C++错误处理嵌套异常error_code修改时间：2026-08-12 06:39:43