C++异常安全保证：从RAII到noexcept策略

背景与问题界定

在金融交易系统的风控引擎中，一个诡异的bug引发了整个交易链路的异常终止：某个字段的std::vector在push_back时因内存不足抛出std::bad_alloc，异常沿调用栈向上传播，导致一个持有互斥锁的作用域被stack unwinding跳过——锁没有释放。这是一个经典的"异常安全基本保证违反"案例。更广泛的问题在于，整个代码库的大部分函数没有明确声明其异常安全级别（Nothrow / Strong / Basic / No guarantee），部分函数混用了throw和返回错误码两种模式，导致调用方无法确定何时应该catch、何时应该检查返回值。C++11/17/20提供了更多的工具（noexcept、move semantics、smart pointers）来实现异常安全，但正确的使用需要贯穿整个架构层面的设计纪律。

目标拆解与工程约束

异常安全级别标注：每个函数需要明确其异常安全保证。C++17引入了noexcept作为类型系统的一部分，noexcept函数可以提供"nothrow"保证。但对于提供Strong或Basic保证的函数，语言层面没有直接标注机制，需要通过文档或convention维持纪律。
Move构造与异常的冲突：std::vector在realloc时，C++11之前的copy+delete操作是异常安全的（如果copy抛出，旧元素还在）。Move构造如果在realloc过程中抛出（通常因为move不是noexcept），vector无法回滚到原始状态。因此，所有用于容器的类型必须提供noexcept的move constructor和move assignment。
异常与线程交互：一个线程中抛出的异常不能被另一个线程catch。C++11的std::exception_ptr可以将异常跨线程传递，但生命周期管理容易出错。交易系统中的异步操作（通过线程池提交的任务）需要统一捕获异常并通过std::future或回调方式传播。
继承与虚函数的异常规范：基类虚函数声明非noexcept，派生类的override也不能是noexcept（反之可以）。如果基类虚函数未声明异常规范，派生类override必须假设它可能会抛出任何异常，这导致类型系统的异常信息完全丢失。

方案设计

我们建立了三级异常安全体制：

第一级：基础设施层的强保证（Strong Guarantee）。对涉及外部系统状态变更的操作（数据库写入、消息发送、文件替换），采用"Commit-or-Rollback"模式。用RAII guard在成功写入后方可"提交"，任何异常抛出都让guard的析构函数完成回滚。

class DbWriteGuard {
    std::function<void()> rollback_;
    bool committed_ = false;
public:
    DbWriteGuard(std::function<void()> rollback) : rollback_(std::move(rollback)) {}
    ~DbWriteGuard() { if (!committed_) rollback_(); }
    void commit() noexcept { committed_ = true; }  // 标记成功
};

void transfer_funds(Account& from, Account& to, int64_t amount) {
    auto guard = DbWriteGuard([&] { undo_transfer(from, to, amount); });
    from.balance -= amount;
    to.balance += amount;
    guard.commit();  // 如果上面任何一行抛出，undo_transfer自动执行
}

第二级：核心逻辑层的Nothrow保证（Noexcept Guarantee）。在性能关键路径上的函数全部标记noexcept，通过前置条件检查确保不会产生异常。这包括所有move构造函数、swap函数、以及热路径上的访问器。

class RiskEngine {
    std::array<Position, 1024> positions_;
public:
    RiskEngine() noexcept = default;
    // Move constructor: noexcept required for standard containers
    RiskEngine(RiskEngine&& other) noexcept 
        : positions_(std::move(other.positions_)) {}
    
    // Hot path: no allocation, no exception
    [[nodiscard]] bool check_threshold(size_t idx, int64_t value) const noexcept {
        return value <= positions_[idx].threshold_;
    }
};

第三级：异步操作的异常传播。所有通过线程池提交的任务使用std::packaged_task，异常被自动捕获到std::future中。调用方通过future.get()或future.wait()获取异常时，异常被重新抛出到调用线程的上下文中。我们进一步封装了一个result<T>类型（类似C++23的std::expected），统一处理同步和异步路径的错误。

实施路径与关键决策

全面启用-Wnoexcept编译警告：使用clang的-Wnoexcept警告禁用掉可以标记为noexcept但未标记的函数。对无法转为noexcept的函数逐一提供注释说明原因（“由于调用外部库X的throw函数”）。
容器元素强制要求noexcept move：所有放入vector、deque、unordered_map的自定义类型，在CI中使用static_assert检查is_nothrow_move_constructible_v<T>。

验证指标与可持续迭代

经过异常安全重构后，风控引擎在故障注入测试（随机在关键路径上注入bad_alloc）中表现出行为确定性。系统不会因为内存分配异常而泄漏锁资源或提交不完整的交易。测试覆盖率通过Lee’s “Exception Safety Test Suite"模式实现——在单元测试中使用自定义分配器在特定位置抛异常，验证状态完整性。

工程落地思考

C++的异常安全不是"捕获还是不捕获"的技术选择，而是一种"处理不可预测失败"的架构哲学。RAII是C++保障异常安全的最强武器——它让资源回滚与执行路径解耦，即使异常穿越十个栈帧，guard的析构函数仍然会执行。noexcept的作用不仅仅是性能优化（编译器可以生成更紧凑的异常表），更是接口契约的声明——调用者知道这个函数不会抛出，因此不需要try-catch包围。但noexcept不是银弹：一个noexcept函数如果内部抛出异常，程序直接terminate，所以noexcept的添加必须以上游调用的noexcept保证为前提。