答案是实现C++类的异常安全需遵循RAII原则、提供强或基本异常保证、采用Copy-and-Swap惯用法、确保析构函数不抛异常，并在性能与安全性间合理权衡，从而防止资源泄露并维持对象状态一致。

在C++中，实现类的异常安全操作，核心在于无论程序何时抛出异常，类实例都能保持其内部状态的有效性，并避免资源泄露。这通常通过智能地管理资源（Resource Acquisition Is Initialization, RAII）和精心设计的成员函数来实现，确保在错误发生时，系统能优雅地恢复或至少不留下烂摊子。

解决方案 要让C++类具备异常安全性，我们通常会围绕以下几个核心原则和技术展开：

1. RAII（Resource Acquisition Is Initialization）原则是基石 RAII是C++处理资源管理和异常安全的核心思想。它要求将所有资源（如内存、文件句柄、网络连接、互斥锁等）的获取与对象的生命周期绑定。资源在构造函数中获取，在析构函数中释放。这样，无论函数正常返回还是抛出异常，析构函数都会被调用，从而保证资源被正确释放，避免泄露。 我个人在实践中发现，很多资源泄露和状态不一致的问题，追根溯源都与没有彻底遵循RAII原则有关。例如，使用

std::unique_ptr

和

std::shared_ptr

来管理动态内存，而不是裸指针；使用

std::lock_guard

或

std::unique_lock

来管理互斥锁，而不是手动调用

lock()

和

unlock()

。这些标准库工具本身就是RAII的典范。

2. 理解并实践三种异常安全保证 在设计类时，我们通常会追求不同级别的异常安全保证：

• 基本保证 (Basic Guarantee): 如果操作抛出异常，程序状态保持有效，没有资源泄露。但对象的状态可能已经改变，且无法预测其具体值。这是最低要求，任何一个健壮的C++类都应该满足。
• 强保证 (Strong Guarantee): 如果操作抛出异常，程序状态保持不变，就像操作从未发生过一样（事务性语义）。这通常是最理想的情况，但实现起来可能需要更多开销。
• 无抛出保证 (No-Throw Guarantee): 操作保证不会抛出任何异常。这通常适用于析构函数、交换操作（

  swap

  ）以及一些简单的查询函数。

3. 采用Copy-and-Swap（拷贝并交换）惯用法实现强保证 对于赋值运算符（

operator=

）或某些修改对象状态的函数，实现强保证的黄金法则就是Copy-and-Swap惯用法。它的核心思想是：

1. 创建一个当前对象的临时副本。
2. 在临时副本上执行所有可能抛出异常的操作。
3. 如果所有操作都成功，则将当前对象的内部状态与临时副本进行交换。
4. 如果操作过程中抛出异常，临时副本会被销毁，而当前对象的状态保持不变。

这是一个经典的例子，展示了如何为一个自定义的字符串类实现异常安全的赋值运算符：

#include <algorithm> // For std::swap #include <cstring>   // For std::strlen, std::strcpy #include <stdexcept> // For std::bad_alloc  class MyString { private:     char* data;     size_t length;  public:     // Default constructor     MyString() : data(nullptr), length(0) {}      // Constructor from C-string     MyString(const char* s) : length(std::strlen(s)) {         data = new char[length + 1]; // Potentially throws std::bad_alloc         std::strcpy(data, s);     }      // Destructor     ~MyString() {         delete[] data;     }      // Copy constructor     MyString(const MyString& other) : length(other.length) {         data = new char[length + 1]; // Potentially throws         std::strcpy(data, other.data);     }      // Move constructor (for efficiency, C++11 onwards)     MyString(MyString&& other) noexcept : data(other.data), length(other.length) {         other.data = nullptr;         other.length = 0;     }      // Non-member swap function (essential for copy-and-swap)     friend void swap(MyString& first, MyString& second) noexcept {         using std::swap; // Enable ADL (Argument Dependent Lookup)         swap(first.data, second.data);         swap(first.length, second.length);     }      // Assignment operator using copy-and-swap idiom     MyString& operator=(MyString other) { // 'other' is passed by value (a copy is made)         swap(*this, other); // Perform the swap         return *this;     }      // Other methods...     const char* c_str() const { return data ? data : ""; }     size_t size() const { return length; } };

在这个例子中，

operator=

接收一个按值传递的

MyString other

。这意味着在进入

operator=

之前，

other

已经是源对象的一个完整副本。如果这个复制过程（即

MyString

的拷贝构造函数）抛出异常，那么

operator=

根本不会被调用，当前对象也就不会受到影响。如果拷贝成功，

swap(*this, other)

会以无抛出的方式交换资源。当

other

离开作用域时，它会销毁原本属于

*this

的旧资源。

4. 仔细设计析构函数和

swap

函数 析构函数绝对不能抛出异常。如果析构函数抛出异常，并且这个异常没有被捕获，那么它会导致程序立即终止（

std::terminate

）。这是因为析构函数通常在栈展开（stack unwinding）过程中被调用，如果此时又抛出异常，会导致两个未处理的异常同时存在，这是C++标准所不允许的。

swap

函数也应该被设计成

noexcept

，因为它通常是Copy-and-Swap惯用法的核心部分，且其操作通常只是交换指针或基本类型，本身不应抛出。

5. 将修改操作隔离 对于那些可能修改对象内部状态的成员函数，如果无法使用Copy-and-Swap，可以尝试将所有可能抛出异常的操作放在函数的前半部分，并且这些操作只作用于局部变量或临时对象。只有当所有这些操作都成功完成后，才将结果“提交”到对象的实际成员变量中。

6. 避免在构造函数中进行复杂且可能抛出异常的操作 如果构造函数抛出异常，对象就没有被完全构造，其析构函数也不会被调用。这意味着在构造函数中分配的任何资源都可能泄露。虽然RAII可以缓解一部分问题（例如智能指针管理的资源），但最好还是保持构造函数的简洁，将复杂的初始化逻辑放到一个单独的

init()

方法中，或者利用工厂函数模式。

为什么异常安全在C++类设计中如此重要？ 异常安全在C++类设计中的重要性，远不止于代码的健壮性。在我看来，它更像是一种契约，是你的类对其使用者做出的承诺。一个不具备异常安全性的类，就像一个随时可能在你背后捅一刀的“队友”，你永远不知道它会在什么时候，以何种方式让你的程序崩溃或数据损坏。

首先，最直接的好处是防止资源泄露。想象一下，你打开了一个文件，分配了一块内存，或者获取了一个互斥锁，结果在这些操作之后，你的代码因为某些原因抛出了异常。如果你的类没有异常安全机制，这些资源可能就永远无法释放，导致文件句柄耗尽、内存溢出或死锁。这对于长时间运行的服务尤其致命。

立即学习“C++免费学习笔记（深入）”；

其次，它维护了数据完整性。一个异常安全的类，即使在操作失败时，也能保证其内部状态的一致性。这意味着，即使某个操作没有完成，对象也不会处于一个“半成品”或“损坏”的状态。这对于依赖于对象内部不变量（invariants）的后续操作至关重要。否则，一个看似无关的异常可能会连锁导致整个系统的数据混乱。

再者，异常安全是构建可靠、可组合软件的基础。当你在构建一个大型系统时，你会将不同的功能封装在不同的类中。如果这些类都做出了异常安全的保证，那么你可以放心地将它们组合起来，而不必担心其中一个组件的失败会彻底破坏整个系统。这种信任关系，大大简化了系统的设计和调试。

最后，从“人”的角度来看，处理一个具有异常安全性的系统，其调试和维护成本会大大降低。那些因为状态不一致或资源泄露导致的、难以复现的Bug，往往是程序员的噩梦。而异常安全，正是为了避免这些噩梦而生。它让你的代码在面对意外时，能够表现出可预测的行为，而不是随机的崩溃。

如何在没有Copy-and-Swap的情况下实现基本异常安全？ 虽然Copy-and-Swap是实现强异常保证的利器，但并非所有场景都适用，或者说，并非所有场景都需要强保证。在某些情况下，我们只需要确保基本异常安全（即不泄露资源，对象处于有效但可能已改变的状态）就足够了。在不使用Copy-and-Swap的情况下，实现基本异常安全的核心在于：

1. 全面拥抱RAII： 这仍然是基石。确保你类中的所有资源，无论是动态内存、文件句柄还是锁，都通过RAII机制进行管理。这意味着，优先使用

   std::unique_ptr

   、

   std::shared_ptr

   、

   std::vector

   、

   std::string

   、

   std::fstream

   、

   std::lock_guard

   等标准库提供的RAII类型。它们在构造时获取资源，在析构时释放资源，天然具备基本异常安全。

2. “先计算，后提交”的策略： 当一个成员函数需要修改对象的多个内部状态时，将所有可能抛出异常的计算或资源分配操作放在函数的前半部分，并且这些操作都作用于局部变量或临时对象。只有当所有这些操作都成功完成后，才将最终的结果一次性地“提交”或赋值给对象的实际成员变量。 例如，一个向

   std::vector

   成员添加元素的函数：

   class MyContainer {     std::vector<int> data; public:     void add_elements(const std::vector<int>& new_elements) {         std::vector<int> temp_data = data; // Make a local copy (or use a temporary vector for new elements)         temp_data.reserve(temp_data.size() + new_elements.size()); // Potentially throws bad_alloc         for (int val : new_elements) {             temp_data.push_back(val); // Potentially throws bad_alloc         }         // All potentially throwing operations are done.         // Now, commit the changes. If an exception occurred above, 'data' remains unchanged.         data = std::move(temp_data); // Use move assignment for efficiency     } };

   在这个例子中，如果

   reserve

   或

   push_back

   抛出异常，

   data

   成员仍然保持原样，没有被部分修改。

3. 避免析构函数抛出异常： 这是基本安全的重要组成部分。如果析构函数内部的代码可能抛出异常（比如关闭文件时磁盘满），你必须在析构函数内部捕获并处理这些异常（例如记录日志），或者直接忽略它们，但绝不能让它们逃逸出析构函数。

   

   Illustroke

   text to SVG，AI矢量插画生成工具

   62

   查看详情

4. 构造函数的异常处理： 如果构造函数抛出异常，对象将不会被完全构造，其析构函数也不会被调用。因此，在构造函数中，任何手动分配的资源（例如裸指针

   new

   出来的内存）都必须通过RAII对象（如智能指针）来管理，以确保即使在构造函数中途抛出异常，这些资源也能被正确清理。

通过这些策略，即使没有Copy-and-Swap的强事务性保证，我们也能确保类在面对异常时，不会造成资源泄露，并且对象总能保持在一个可用的状态。

异常安全对性能有什么影响，我们应该如何权衡？ 谈到异常安全对性能的影响，这确实是一个值得深思的问题，尤其是在C++这样一个追求极致性能的语言中。我经常看到有人担心异常处理机制本身的开销，或者为了实现异常安全而采取的某些策略会拖慢程序。

首先，关于异常处理机制本身的开销： 如果程序不抛出异常，那么

try-catch

块的运行时开销通常是微乎其微的，现代编译器在这方面做了大量优化。真正的性能成本发生在异常被抛出时。此时，C++运行时需要进行栈展开（stack unwinding），这涉及遍历调用栈，查找匹配的

catch

块，并在此过程中销毁所有局部对象。这个过程确实会比正常执行路径慢很多，因为它需要做更多的工作。 所以，一个常见的误解是“

try-catch

很慢”。更准确的说法是“抛出异常很慢”。因此，异常应该用于处理真正的“异常”情况，而不是作为常规的错误处理流程（例如，不应该用异常来表示用户输入无效，那更适合返回错误码）。

其次，关于实现异常安全策略的开销：

• Copy-and-Swap惯用法： 这是最常被提及的性能权衡点。为了实现强保证，Copy-and-Swap需要创建一个临时对象副本，这在对象包含大量数据时（例如一个巨大的

  std::vector

  或

  std::string

  ），可能会导致显著的内存分配和数据拷贝开销。

• RAII对象的开销： 智能指针（

  std::unique_ptr

  、

  std::shared_ptr

  ）相比裸指针会有轻微的开销，比如

  shared_ptr

  需要维护引用计数。但这些开销通常是可忽略不计的，并且与它们带来的安全性和便利性相比，微不足道。

如何进行权衡？

1. 明确所需的异常安全级别： 并非所有操作都需要强保证。

   • 对于那些修改外部可见状态、且失败会导致数据不一致的“事务性”操作，强保证是值得追求的。例如，数据库事务、文件系统操作，或者像

     std::vector::push_back

     这样可能重新分配内存的操作。

   • 对于大部分内部操作，或者那些即使失败也只影响对象局部、且不泄露资源的操作，基本保证可能就足够了。例如，一个日志记录器，如果写入失败，我们可能只要求它不崩溃、不泄露文件句柄，而不是要求所有日志都被写入或都没有被写入。
   • 对于析构函数和

     swap

     操作，无抛出保证是强制性的。

2. 利用C++11及以后的移动语义： Copy-and-Swap的性能问题在很大程度上可以通过移动语义来缓解。当

   operator=

   接收一个右值引用时，拷贝操作可以被优化为移动操作，避免了深拷贝。即使是按值传递的Copy-and-Swap，在某些情况下编译器也能通过RVO（Return Value Optimization）或NRVO（Named Return Value Optimization）减少拷贝。更重要的是，

   std::swap

   函数通常会利用移动语义，使得交换的开销非常小。

3. “不要过早优化”： 在设计之初，我倾向于优先考虑代码的正确性和健壮性，即先实现异常安全。只有当性能分析（profiling）明确指出异常安全机制是性能瓶颈时，我才会考虑优化。很多时候，我们臆想的性能问题，在实际运行时根本不构成瓶颈。

4. 考虑替代的错误处理机制： 在极度性能敏感的“热路径”代码中，有时会选择返回错误码或使用

   std::optional

   /

   std::expected

   来避免异常的开销。但这会增加调用者的负担，因为他们必须显式检查每个函数的返回值。这是一个设计哲学上的权衡：是让调用者承担错误检查的责任，还是让异常机制在幕后处理？

总而言之，异常安全是C++构建可靠系统的基石。虽然它可能带来一些性能上的考量，但现代C++的特性（如移动语义）和编译器优化已经大大减轻了这些负担。在大多数情况下，为你的类实现适当的异常安全保证，带来的收益（更少的Bug、更高的可靠性、更低的维护成本）远超