C++异常处理实战：正确使用noexcept与保障异常安全

在 C++ 开发中，异常处理是一个强大但容易被误用的机制。很多开发者对异常处理存在误解，认为它“慢”或者“复杂”，甚至完全避免使用异常。但实际上，只要掌握正确的姿势，异常处理可以让代码更加健壮、清晰和高效。今天，我们就来深入聊聊，特别是在那些我们宣称“不抛出异常”的场景下，如何正确地使用现代 C++ 提供的工具，并确保代码的安全与性能。

一、异常规格说明：从throw()到noexcept

1.1 传统的异常规格说明

在 C++11 之前，我们使用 throw() 来声明函数不会抛出任何异常：

void func() throw(); // 声明func不会抛出异常

然而，这种方式存在一些问题：

• 运行时开销大：需要运行时检查。
• 编译器优化受限：无法进行针对性优化。
• 语义偏差：C++98 中 throw() 函数若抛出异常，会调用 std::unexpected() 而非直接终止。

1.2 C++11 的 noexcept 关键字

C++11 引入了 noexcept 关键字，它解决了传统异常规格说明的问题：

void func() noexcept; // 声明func不会抛出异常

noexcept 的优势：

• 编译期可验证的异常契约。
• 减少运行时开销，允许编译器进行激进优化。
• 支持条件性异常声明。
• 与标准库深度协同。

1.3 noexcept 的使用场景

• 移动构造/赋值运算符：优先声明 noexcept。
• swap 函数：必须声明 noexcept。
• 析构函数：依赖默认 noexcept(true)，无需显式声明。
• 资源释放函数：声明 noexcept。
• 简单数学运算、无外部依赖的工具函数：声明 noexcept。

二、noexcept优化：性能与安全的平衡

2.1 编译器优化

当函数被标记为 noexcept 时，编译器可以：

• 省略生成异常处理相关的代码。
• 减少二进制体积。
• 避免运行时在调用点插入隐式 std::terminate() 检查分支。

2.2 影响标准库行为

标准容器（如 std::vector）在扩容时会根据移动构造函数是否 noexcept 来选择移动或拷贝：

class NoexceptMovable {
public:
    NoexceptMovable(NoexceptMovable&& other) noexcept { // 移动构造函数标记为noexcept
        data = other.data;
        other.data = nullptr;
    }
private:
    int* data;
};

如果移动构造函数是 noexcept，容器会选择移动操作，性能更高；否则会退化为拷贝构造，性能损失显著。这体现了异常安全对系统性能的直接影响。

2.3 异常传播处理

• 没有 noexcept 修饰的函数会按照调用栈依次往上传播异常。
• 有 noexcept 修饰的函数不会传播异常，直接调用 terminate 终止程序。

三、异常安全等级：从无保证到不抛出保证

3.1 异常安全的四个等级

3.1.1 无保证（No Guarantee）

• 当操作过程中抛出异常时，程序状态变得不确定。
• 对象可能被破坏，数据结构可能陷入无效状态。
• 资源可能泄漏。
• 这是最糟糕的情况，通常是 Bug 和崩溃的根源。

3.1.2 基本保证（Basic Guarantee）

• 在操作失败并抛出异常后，程序状态保持不变。
• 所有对象仍然有效且可析构，不会发生资源泄漏。
• 但程序的具体状态可能是操作前的原始状态，也可能是某个确定的中间状态。

3.1.3 强保证（Strong Guarantee）

• 操作具有“原子性”。
• 要么完全成功，将程序置于目标新状态。
• 要么因异常而完全失败，程序状态回滚到操作调用前的精确状态。
• 这就是著名的 “commit-or-rollback” 语义。

3.1.4 不抛出保证（Nothrow Guarantee）

• 承诺操作永远不会抛出异常。
• 无论发生什么，它都会成功执行完毕。
• 适用场景：析构函数、内存释放操作、swap 函数等。

3.2 实现强保证的关键技术

3.2.1 RAII（资源获取即初始化）

RAII 是实现基本保证和强保证的基石。它是现代 C++ 资源管理的核心思想，确保了资源的自动清理。想深入理解其在复杂系统中的实践，可以参考 C/C++ 板块的相关讨论。

void processFile(const std::string& filename) {
    std::ifstream file(filename);
    if (!file) throw std::runtime_error(“无法打开文件”);
    // 操作文件...
}

在这个函数里，如果抛出异常，file 对象会自动关闭，不需要手动写 try-catch 去清理。

3.2.2 Copy-and-Swap 惯用法

Copy-and-Swap 是实现强保证的常用技术：

class MyClass {
private:
    std::string name;
    std::vector<int> data;
public:
    MyClass& operator=(MyClass other) {  // 传值！
        swap(*this, other);
        return *this;
    }
    friend void swap(MyClass& a, MyClass& b) noexcept {
        using std::swap;
        swap(a.name, b.name);
        swap(a.data, b.data);
    }
};

这种方法天然支持强异常安全，因为所有可能失败的工作都在临时对象上完成，只有所有工作都成功后，才用一个不抛出异常的 swap 操作来“提交”更改。

四、move 操作异常安全：高效与安全的平衡

4.1 移动操作的特殊性

移动操作通常是用来“偷”资源的，比如指针、句柄等。理论上它不应该抛出异常，因为很多标准库容器在扩容或重新分配内存时会依赖移动操作的异常安全性。

4.2 移动操作的异常安全实现要点

4.2.1 确保移动操作不抛出异常

一个最佳实践是：确保你的移动构造函数和移动赋值运算符不抛出异常，并用 noexcept 来显式声明：

class ResourceHolder {
public:
    ResourceHolder(ResourceHolder&& other) noexcept {
        data = other.data;
        other.data = nullptr;
    }
private:
    int* data;
};

4.2.2 避免在移动构造中调用可能抛出的函数

在移动构造函数的设计中，应避免调用可能抛出异常的函数：

// 错误示例
class BadMove {
public:
    BadMove(BadMove&& other) {
        data = new int[100]; // 可能抛出std::bad_alloc
        std::copy(other.data, other.data + 100, data);
        delete[] other.data;
        other.data = nullptr;
    }
private:
    int* data;
};

// 正确示例
class GoodMove {
public:
    GoodMove(GoodMove&& other) noexcept
        : data(other.data) {
        other.data = nullptr; // 简单指针转移，不会抛出
    }
private:
    int* data;
};

4.3 标准库容器对移动操作的异常要求

大多数标准容器要求移动操作不抛出异常，以确保强异常安全保证。例如，std::vector 在重新分配内存时依赖移动操作的稳定性。这种对性能和安全性的权衡，是设计和实现高并发、高可用系统时必须考虑的关键点，你可以在 后端 & 架构 板块找到更多相关的深入分析。

当移动构造函数未声明为 noexcept 时，标准库可能退化为复制操作以保障安全，这将直接影响性能。

---

希望这篇关于 C++ 异常处理，特别是 noexcept 使用和异常安全保障的文章，能帮助你写出更健壮、更高效的代码。编程实践中，对细节的掌控往往决定了系统的稳定性和性能上限。欢迎在 云栈社区 继续探讨相关技术话题。