异常安全与错误处理：异常安全保证级别、RAII与异常、noexcept说明符、错误码与异常的选择

异常安全这个话题，说实话，很多C++开发者写了三五年代码都不一定真正搞明白。我见过太多项目，异常处理写得跟碰运气似的——要么到处try-catch，要么干脆禁用异常。这两种极端，其实都挺可惜的。

今天咱们就把异常安全这块彻底聊透。从最基本的保证级别，到RAII的最佳实践，再到noexcept的微妙之处，最后聊聊什么时候该用异常、什么时候该用错误码。嗯，内容不少，但都是干货。

异常安全保证级别：你的代码到底有多安全？

异常安全不是玄学，它有一套明确的评级标准。Abrahams在2001年就提出了这套分级，到现在依然是业界公认的准则。

级别	含义	通俗理解
无保证	异常发生后，资源可能泄漏，数据可能损坏	听天由命
基本保证	异常发生后，不泄漏资源，对象处于有效但不确定的状态	至少不崩
强保证	异常发生后，状态回滚到操作之前	要么全做，要么不做
不抛异常	保证操作永远不会抛出异常	绝对安全

我个人习惯，核心数据结构至少要做到强保证。为什么？因为一旦数据损坏，排查起来极其痛苦。我曾经在一个交易系统里遇到过，某个操作抛出异常后，账户余额和交易记录对不上了——那真是噩梦般的调试经历。

RAII与异常：天生一对

RAII（资源获取即初始化）是C++异常安全的基石。你想想看，如果资源管理都交给析构函数，异常发生时栈展开会自动调用析构函数，资源自然就释放了。

// 不安全的写法
void process() {
    int* data = new int[100];
    // 如果这里抛出异常，data就泄漏了
    doSomething(data);  // 可能抛异常
    delete[] data;
}

// RAII的安全写法
void process() {
    std::vector<int> data(100);
    doSomething(data.data());  // 即使抛异常，vector析构也会释放内存
}

这里有个坑，我提醒一下：不要在构造函数里做可能失败的操作。如果构造函数抛异常，对象还没构造完成，析构函数不会被调用。那已经分配的资源怎么办？

RAII的另一个妙用是作用域锁。std::lock_guard就是典型例子：

void transfer(Account& from, Account& to, double amount) {
    std::lock_guard<std::mutex> lock1(from.mutex);
    std::lock_guard<std::mutex> lock2(to.mutex);
    // 即使这里抛异常，锁也会自动释放
    from.withdraw(amount);
    to.deposit(amount);
}

你看，异常发生时栈展开，lock_guard的析构函数自动释放互斥锁。这就是RAII的魅力——异常安全不是靠人肉try-catch，而是靠设计模式。

noexcept说明符：承诺的力量

noexcept是C++11引入的关键字，它告诉编译器：这个函数不会抛异常。这不仅仅是一个文档注释，它会影响编译器的优化决策。

void safeFunction() noexcept {
    // 如果这里真的抛了异常，程序会直接终止
    // 而不是正常展开栈
}

void maybeThrow() {
    // 可能抛异常
}

为什么要有noexcept？两个原因：

• 性能优化：编译器知道不会抛异常，可以生成更紧凑的代码，不需要维护异常处理栈帧
• 移动语义：std::vector在重新分配时，如果移动构造函数是noexcept的，就会用移动而不是拷贝，性能提升巨大

但要注意，noexcept不是银弹。滥用noexcept会导致程序直接终止——这比优雅地处理异常要粗暴得多。我的原则是：只有确定不会抛异常的函数才标记noexcept，不确定的就别加。

错误码与异常的选择：什么时候用哪个？

这个问题在C++社区争论了十几年。我的观点很明确：异常用于异常情况，错误码用于预期错误。

什么叫异常情况？文件找不到、网络断开、内存不足——这些是程序正常流程中不应该发生的。什么叫预期错误？用户输入格式不对、网络请求超时——这些是业务逻辑的一部分。

场景	推荐方式	理由
构造函数失败	异常	构造函数没有返回值，只能用异常
运算符重载	异常	运算符也没有返回值通道
频繁发生的错误	错误码	异常有性能开销，高频场景不合适
跨模块调用	错误码	异常可能跨DLL边界，行为未定义
核心业务逻辑	异常	错误码容易被忽略，异常强制处理

我个人习惯，在库的内部使用异常，在库的边界用错误码。这样既享受了异常的好处，又避免了跨模块的问题。

// 使用expected模式
std::expected<int, std::error_code> parseNumber(const std::string& s) {
    try {
        return std::stoi(s);
    } catch (const std::invalid_argument&) {
        return std::unexpected(make_error_code(ParseError::InvalidInput));
    } catch (const std::out_of_range&) {
        return std::unexpected(make_error_code(ParseError::OutOfRange));
    }
}

// 调用方可以优雅地处理
auto result = parseNumber(input);
if (!result) {
    // 处理错误
    logError(result.error());
    return;
}
// 使用result.value()

你看，这样既保留了异常在内部的使用，又在接口层面提供了清晰的错误处理路径。说白了，就是取两者的长处。

知识体系总览

下面这张图总结了异常安全与错误处理的核心脉络：

总结一下今天的核心内容：异常安全不是靠运气，而是靠设计。RAII是地基，noexcept是承诺，错误码和异常的选择是权衡。把这些搞明白了，你的C++代码才能真正做到健壮可靠。

嗯，今天就聊到这里。记住一句话：好的错误处理，是让错误变得不可能发生，而不是等发生了再去处理。

---