C++异常处理深度解析：从原理到实践，构建健壮代码的基石

1. 项目概述：为什么C++异常处理值得你花时间深究？

在C++开发这条路上，无论是刚入门的新手，还是摸爬滚打多年的老手，都绕不开一个既基础又复杂的主题：异常处理。你可能已经习惯了用if (ptr == nullptr)来检查空指针，用函数返回值来标识错误，但当你面对一个大型项目，函数调用层级深、资源管理复杂时，传统的错误处理方式很快就会变得像一团乱麻，代码里充斥着if-else和错误码检查，核心业务逻辑反而被淹没了。这就是C++异常处理机制存在的核心价值——它提供了一种将错误处理逻辑与正常业务逻辑分离的标准化方式。

简单来说，异常处理就是一套“消防预案”。你的程序正常运行时是“安全状态”，一旦发生预料之外的“火灾”（比如内存不足、文件打开失败、除零错误），异常机制能让你不必在每个房间（函数）都准备灭火器（错误检查），而是建立一个统一的“消防通道”（异常抛出）和“消防站”（异常捕获），让程序能够有序地报告错误、清理现场并尝试恢复或优雅退出。最近社区里关于visual c++ redistributable、vscode配置c/c++环境以及各种c++面试题、c++八股文的讨论热度很高，而异常处理恰恰是面试中高频出现的深度考点，也是写出健壮、可维护的C++代码的基石。无论是开发c++小游戏处理用户输入，还是用opencv c++做图像处理时应对摄像头断开，亦或是实现c++多线程时处理线程同步失败，一套清晰的异常处理策略都至关重要。

这篇文章，我将从一个写过无数try-catch块、也踩过无数相关坑的开发者角度，带你彻底拆解C++的异常处理机制。我们不只讲try、throw、catch这三个关键字怎么用，更要深入背后：异常抛出时栈是如何展开（Stack Unwinding）的？构造函数和析构函数中的异常有什么“坑”？noexcept关键字到底在向编译器和运行时承诺什么？为什么说异常安全（Exception Safety）有不同等级？我会结合具体的代码示例，比如在c++结构体链表操作中，或是模拟c++回调函数调用失败时，来展示异常处理的最佳实践和常见陷阱。目标是让你读完不仅能应付面试，更能真正在项目中自信、正确地使用异常，写出更健壮的C++代码。

2. 异常处理的核心机制与工作原理解析

要玩转异常，必须先理解它的运行机制。这不像学一个库函数调用那么简单，它涉及到程序执行流的根本性改变，并且与编译器和运行时库深度绑定。

2.1 基本语法与执行流程：try,throw,catch

这三个关键字构成了异常处理的基本骨架，它们的协作流程是理解一切的基础。

#include <iostream> #include <stdexcept> double divide(int a, int b) { if (b == 0) { throw std::runtime_error("Division by zero!"); } return static_cast<double>(a) / b; } int main() { int x = 10, y = 0; try { double result = divide(x, y); std::cout << "Result: " << result << std::endl; } catch (const std::runtime_error& e) { std::cerr << "Caught an exception: " << e.what() << std::endl; } catch (...) { // 捕获所有其他类型的异常 std::cerr << "Caught an unknown exception!" << std::endl; } std::cout << "Program continues after exception handling." << std::endl; return 0; }

执行流程拆解：

1. try块定义监控范围：程序进入try块正常执行。try块定义了异常的“监控区”，这里面的代码如果抛出异常，就会被后续的catch块处理。
2. throw抛出异常对象：当divide函数中b == 0条件成立时，throw语句被执行。这里的关键是，throw并不是简单地跳转，而是构造一个异常对象（这里是std::runtime_error的临时对象）。这个对象可以是我们自定义类的实例，但更常见的是使用标准库中派生自std::exception的异常类型。
3. 栈展开（Stack Unwinding）：这是异常机制最核心也最微妙的部分。当throw发生后，程序会立即停止当前的正常执行流，开始从抛出点向外层逐层退出函数调用栈（即“栈展开”）。在退出每一层栈帧（即每一个函数作用域）时，一个重要的事情发生了：该作用域内所有已构造的局部对象的析构函数会被自动调用。这是确保资源不泄露（如内存、文件句柄、锁）的生命线。例如，如果try块里或divide函数里定义了std::vector或std::fstream对象，在栈展开经过它们时，它们的析构函数会被正确调用以释放资源。
4. catch块匹配并处理：栈展开会一直进行，直到找到一个能处理该类型异常的catch块。catch块通过其参数类型来匹配异常对象的类型。匹配规则类似于函数参数匹配，允许通过基类引用捕获派生类异常（这正是为什么推荐自定义异常继承自std::exception）。一旦匹配成功，程序就进入这个catch块执行处理代码。catch (...)是“全捕获”子句，能匹配任何类型的异常，通常用于最后的兜底处理。
5. 处理后的执行流：catch块执行完毕后，程序会继续执行该catch块之后的所有代码（如上例中输出 “Program continues…”）。异常被成功捕获和处理，程序得以继续运行。

注意：如果抛出的异常始终没有被任何catch块捕获（即栈展开到了main函数之外），std::terminate会被调用，默认行为是终止程序。这在调试时往往表现为程序崩溃。

2.2 栈展开（Stack Unwinding）的深度剖析

栈展开是异常安全性的基石，但也是最容易让人困惑的地方。我们通过一个更复杂的例子来看。

#include <iostream> #include <memory> class Resource { public: Resource(int id) : id_(id) { std::cout << "Resource " << id_ << " acquired.\n"; } ~Resource() { std::cout << "Resource " << id_ << " released.\n"; } private: int id_; }; void functionC() { Resource res3(3); throw std::runtime_error("Error from functionC"); // res3 的析构函数会在 throw 之后的栈展开中被调用 } void functionB() { Resource res2(2); functionC(); // 如果 functionC 抛出异常，res2 的析构函数会在栈展开经过 functionB 时被调用 } void functionA() { Resource res1(1); try { functionB(); } catch (const std::exception& e) { std::cerr << "Caught in functionA: " << e.what() << std::endl; } } int main() { functionA(); return 0; }

运行这个程序，输出将会是：

Resource 1 acquired. Resource 2 acquired. Resource 3 acquired. Resource 3 released. Resource 2 released. Caught in functionA: Error from functionC Resource 1 released.

关键点解析：

• 析构顺序：输出清晰地展示了栈展开的“反向”顺序：res3->res2。这正是函数调用栈（后进先出）的体现。functionC中的res3最先构造、最后析构（在functionC栈帧退出时），functionB中的res2随后析构。
• 资源管理：即使functionC因异常而提前退出，res3和res2的资源（在这个例子里是模拟的）都得到了正确释放。这就是RAII（Resource Acquisition Is Initialization）理念与异常机制完美结合的魅力：将资源管理封装在对象生命周期中，依赖析构函数自动释放，从而在异常发生时也能保证资源安全。
• functionA中的res1：注意res1的析构发生在catch块执行之后。因为res1是在functionA的局部作用域内，而catch块也在同一个作用域内。只有当functionA这个函数完全退出时（catch块执行完毕，继续执行到函数末尾），res1的生命周期才结束，其析构函数被调用。

栈展开的潜在陷阱：如果析构函数本身也抛出异常会怎样？这会导致程序立即调用std::terminate终止。因为C++运行时无法同时处理两个活跃的异常。因此，析构函数必须绝不抛出异常，这是一个铁律。通常需要在析构函数内部用try-catch(...)吞掉所有可能的异常。

2.3 异常对象与异常类型体系

throw抛出的可以是一切可以被复制的对象，但最佳实践是使用标准库或自定义的异常类。

标准异常体系：<stdexcept>头文件定义了一系列常用的标准异常，它们都继承自std::exception。

• std::logic_error：程序逻辑错误，理论上可以在编码阶段避免。
  • std::invalid_argument：无效参数。
  • std::out_of_range：访问越界，比如vector::at。
  • std::length_error：试图创建超出最大长度的对象。
• std::runtime_error：运行时错误，通常由外部因素引起，难以在编码时预知。
  • std::overflow_error/std::underflow_error：算术溢出/下溢。
  • std::system_error：系统调用错误（C++11引入，包含错误码）。

使用标准异常的好处是它们都提供了what()成员函数返回错误描述，并且有清晰的类型层次，便于捕获。

自定义异常类：当标准异常不足以描述你的错误时，可以自定义。

class MyNetworkException : public std::runtime_error { public: MyNetworkException(const std::string& msg, int errorCode) : std::runtime_error(msg), errorCode_(errorCode) {} int getErrorCode() const { return errorCode_; } private: int errorCode_; }; // 使用 void connectToServer() { if (/* 连接失败 */) { throw MyNetworkException("Connection failed", 1001); } } // 捕获时可以精确匹配 try { connectToServer(); } catch (const MyNetworkException& e) { std::cerr << "Network error " << e.getErrorCode() << ": " << e.what() << std::endl; } catch (const std::exception& e) { // 兜底捕获其他标准异常 }

实操心得：自定义异常时，务必以public方式继承自std::exception或其派生类（如std::runtime_error）。这样既可以利用多态通过基类引用捕获，又能通过what()获取基本信息，还能添加你自己的额外信息（如错误码、错误位置等）。避免直接throw一个基本类型（如throw “error”;），这会让错误处理变得难以维护。

3. 异常安全（Exception Safety）的等级与实现策略

异常处理不仅仅是try-catch，更重要的是保证当异常发生时，你的程序状态（尤其是数据）不会崩溃或处于不可预测的状态。这就是“异常安全”。它通常被分为几个等级，理解这些等级是编写健壮C++代码的关键。

3.1 异常安全保证的三个级别

1. 基本保证（Basic Guarantee）：如果异常被抛出，程序仍处于有效状态。没有资源泄漏，所有对象仍可被安全地析构，但程序的具体状态可能是未知的（比如，一个容器的部分元素可能已被修改）。这是最低要求，通常通过RAII来保证资源不泄露。
2. 强保证（Strong Guarantee）：如果操作因异常而失败，程序状态完全回滚到操作调用之前，就像这个操作从未执行过一样。这通常意味着操作具有“事务性”（Transactional）。实现强保证往往需要额外的开销，比如先在一个临时副本上操作，成功后再用noexcept的swap来替换原对象。
3. 不抛异常保证（Nothrow Guarantee）：承诺该操作绝不会抛出任何异常。这通常适用于简单的getter、析构函数、移动操作等。在C++11后，可以用noexcept关键字来显式声明。

3.2 实现异常安全的关键技术：RAII与copy-and-swap

RAII（资源获取即初始化）是实现基本保证的基石。其核心思想是：将资源的生命周期与一个对象的生命周期绑定。在构造函数中获取资源，在析构函数中释放资源。这样，无论函数是正常返回还是因异常退出，只要对象离开其作用域，析构函数就会被调用，资源就能确保被释放。智能指针（std::unique_ptr,std::shared_ptr）、容器、文件流等都是RAII的典范。

// 不安全的做法 void unsafeFunction() { int* ptr = new int[100]; someOperationThatMayThrow(); // 如果这里抛出异常，内存泄漏！ delete[] ptr; } // 安全的RAII做法 void safeFunction() { std::vector<int> vec(100); // 使用vector管理内存 someOperationThatMayThrow(); // 即使这里抛出异常，vec的析构函数也会自动释放内存 }

copy-and-swap惯用法是实现强保证的经典技术。其核心是：任何可能失败的操作，都先在一个局部副本上进行，待所有操作都成功后，再用一个不会失败的操作（如swap）来替换原对象的状态。

class StringArray { public: // ... 其他成员函数 void append(const std::string& str) { // 1. 创建当前状态的副本 StringArray temp(*this); // 2. 在副本上执行可能失败的操作 temp.data_.push_back(str); // push_back 可能因内存不足而抛出 std::bad_alloc // 3. 如果上一步成功，用 noexcept 的 swap 交换状态 swap(temp); // 假设 swap 被实现为 noexcept } void swap(StringArray& other) noexcept { using std::swap; swap(data_, other.data_); } private: std::vector<std::string> data_; };

在这个例子中，append操作提供了强保证：如果push_back失败（抛出std::bad_alloc），异常会传播出去，但*this对象的状态完全没有被改变，因为所有修改都发生在临时对象temp上。只有所有操作都成功，才会通过swap原子性地更新状态。

注意事项：copy-and-swap虽然强大，但涉及一次完整的拷贝，可能有性能开销。需要根据实际情况在性能和异常安全之间权衡。对于许多标准库容器操作（如std::vector::push_back），它们自身在可能重新分配内存时，内部已经实现了类似强保证或至少基本保证的机制。

3.3 构造函数与析构函数中的异常处理

这是异常安全中的两个特殊且重要的场景。

构造函数中的异常：如果一个对象的构造函数在执行过程中抛出异常，那么：

• 这个对象的构造被视为失败，其析构函数不会被调用（因为对象并未完全构造成功）。
• 但是，对于该对象的所有已成功构造的成员子对象和基类子对象，它们的析构函数会被依次调用（顺序与构造顺序相反）。这就是为什么成员变量最好也使用RAII对象（如智能指针、标准容器），这样即使构造函数中途失败，已分配的资源也能被自动清理。

class Widget { public: Widget() : ptr1(new int(42)), ptr2(new int(100)) { // 假设 new int(100) 成功，但接下来抛异常 throw std::runtime_error("Construction failed!"); // 此时，ptr1 指向的内存会泄漏吗？不会！ // 因为ptr1是内置指针，不是RAII对象。这里会内存泄漏！ } private: int* ptr1; // 危险！裸指针 int* ptr2; };

为了避免上述内存泄漏，必须使用RAII：

class SafeWidget { public: SafeWidget() : uptr1(std::make_unique<int>(42)), uptr2(std::make_unique<int>(100)) { throw std::runtime_error("Construction failed!"); // 异常抛出时，uptr1和uptr2的析构函数会被调用，自动释放内存。 } private: std::unique_ptr<int> uptr1; // 安全 std::unique_ptr<int> uptr2; };

析构函数中的异常：如前所述，析构函数绝不能抛出异常。如果析构函数中执行的操作可能失败（比如关闭文件、网络连接），必须在其内部进行捕获和处理，防止异常传播到析构函数之外。

class FileHandler { public: ~FileHandler() noexcept { // 最好声明为 noexcept try { if (file_.is_open()) { file_.close(); // close() 可能失败 } } catch (...) { // 记录日志，但绝不能重新抛出 std::cerr << "Failed to close file in destructor, ignoring.\n"; // 通常在这里会记录到日志系统，而不是cout/cerr } } private: std::fstream file_; };

4. C++11/17/20 中异常处理的现代特性

现代C++标准引入了一些重要特性来增强和优化异常处理。

4.1noexcept关键字：性能优化与契约声明

noexcept有两个主要作用：

1. 异常规范：声明一个函数不会抛出任何异常。这不同于旧的throw()声明。noexcept是函数接口的一部分，调用者可以依赖这个承诺。

   void mySwap(int& a, int& b) noexcept { int temp = a; a = b; b = temp; }

2. 运算符：作为一个运算符，noexcept(expression)可以在编译期判断一个表达式是否被声明为不抛异常。这在模板元编程和条件noexcept声明中非常有用。

   template <typename T> void swap(T& a, T& b) noexcept(noexcept(a.swap(b))) { a.swap(b); } // 这个swap函数是否noexcept，取决于 T::swap 是否noexcept。

为什么noexcept重要？

• 性能优化：编译器知道一个函数是noexcept后，可以生成更高效的代码，因为它不需要为栈展开准备复杂的异常处理表（exception table）。
• 移动语义：标准库中的许多操作（如std::vector::resize、std::vector::push_back）在元素类型具有noexcept移动构造函数时，会优先使用移动而非拷贝，因为这能提供更强的异常安全保证（移动操作失败时，源对象状态可能改变，但至少不会泄漏）。
• 契约与文档：它向函数的用户明确声明了行为，是接口设计的一部分。

实操心得：不要滥用noexcept。只在你绝对确定函数不会抛出任何异常，并且未来也不会修改为可能抛出异常时，才使用它。将一个可能抛出的函数错误地声明为noexcept，当异常真的发生时，程序会直接调用std::terminate终止，而不是进行正常的栈展开和捕获，这通常是灾难性的。对于析构函数、移动操作、交换操作，应尽量使其成为noexcept。

4.2 异常指针std::exception_ptr与跨线程异常传递

在多线程编程中，一个线程中抛出的异常无法被另一个线程直接捕获。C++11引入了std::exception_ptr来解决这个问题。它是一个共享的、类型擦除的智能指针，可以捕获任何异常（通过std::current_exception()），并稍后在另一个线程中重新抛出（通过std::rethrow_exception）。

#include <iostream> #include <thread> #include <future> #include <exception> void mayThrow() { throw std::runtime_error("Exception from thread"); } int main() { std::exception_ptr eptr; std::thread t([&eptr] { try { mayThrow(); } catch (...) { // 捕获所有异常，并存储到 exception_ptr 中 eptr = std::current_exception(); } }); t.join(); // 在主线程中处理子线程的异常 if (eptr) { try { std::rethrow_exception(eptr); } catch (const std::exception& e) { std::cerr << "Caught exception from thread: " << e.what() << std::endl; } } return 0; }

std::future也利用了这种机制，当你调用future::get()时，如果异步操作中抛出了异常，它会被重新抛出到调用get()的线程中。

4.3 嵌套异常std::nested_exception

在处理异常时，有时你想捕获一个异常，进行一些处理（比如记录日志、转换错误类型），然后抛出一个新的异常，但同时又不丢失原始的异常信息。std::nested_exception和std::throw_with_nested提供了这种能力。

#include <iostream> #include <exception> #include <stdexcept> void lowLevelFunction() { throw std::runtime_error("Low-level I/O error"); } void highLevelFunction() { try { lowLevelFunction(); } catch (...) { // 捕获低级异常，包装成更高级的异常再抛出，同时保留原始异常 std::throw_with_nested(std::logic_error("High-level operation failed")); } } int main() { try { highLevelFunction(); } catch (const std::exception& e) { std::cerr << "Caught: " << e.what() << std::endl; // 尝试解包嵌套的异常 try { std::rethrow_if_nested(e); } catch (const std::exception& nested) { std::cerr << " Nested: " << nested.what() << std::endl; } } return 0; }

这对于构建清晰的错误传播链非常有用，尤其是在分层架构的软件中。

5. 异常处理的最佳实践、常见陷阱与性能考量

掌握了机制和特性，最终要落地到如何用好。这里总结一些血泪教训换来的最佳实践。

5.1 何时该用异常？何时不该用？

应该使用异常的情况：

• 无法在本地处理的错误：当函数检测到一个错误，但它自身缺乏足够的上下文来恢复或做出有意义的处理时，应该抛出异常，让上层调用者决定如何应对。例如，一个解析配置文件的函数，遇到格式错误时，它自己无法决定是退出程序、使用默认值还是提示用户，应该抛出异常。
• 构造函数失败：构造函数没有返回值，报告失败的唯一标准方式就是抛出异常。
• 操作符重载失败：像operator[]、operator/这类操作符，很难通过返回值来有效表示错误，使用异常更合适。
• 跨多层函数调用的错误传播：当错误需要穿透很多层中间函数才能到达处理逻辑时，使用异常可以避免每一层都进行错误码检查和传递，保持代码清晰。

不应该使用异常的情况：

• 可预见的、频繁发生的控制流：例如，在遍历中查找一个元素，没找到是正常情况，应该用返回值（如end()迭代器）或std::optional来表示，而不是抛出异常。异常机制有开销，不适合用于常规控制流。
• 析构函数中：如前所述，析构函数必须处理掉所有异常，绝不能抛出。
• 内存分配失败（new）：在现代操作系统中，new在内存不足时默认抛出std::bad_alloc。但对于一些实时或嵌入式系统，可能更倾向于使用nothrow版本的new并检查空指针。
• 与C语言或没有异常机制的代码交互：跨越语言边界时（如C++回调给C函数），异常必须被捕获并转换为错误码，否则会导致未定义行为。

5.2 常见陷阱与避坑指南

1. 切片问题（Slicing）：通过值捕获异常对象会导致对象切片，丢失派生类的信息。务必通过引用捕获。

   // 错误做法：切片 catch (std::exception e) { ... } // 正确做法：通过 const 引用捕获 catch (const std::exception& e) { ... }

2. 捕获顺序问题：catch子句的匹配是按书写顺序进行的。因此，应该先捕获更特化（派生类）的异常，再捕获更泛化（基类）的异常。

   try { ... } catch (const MyNetworkException& e) { ... } // 先捕获具体的 catch (const std::runtime_error& e) { ... } // 再捕获基类 catch (const std::exception& e) { ... } // 最后捕获最通用的 catch (...) { ... } // 兜底

3. 在析构函数中抛出异常：这是致命错误，会导致std::terminate。务必在析构函数内部try-catch(...)。

4. 异常安全问题：编写可能抛出异常的函数时，时刻思考其异常安全等级。优先使用RAII管理资源，对于关键操作考虑使用copy-and-swap实现强保证。

5. 不要吞掉所有异常而不做记录：catch (...) { }是一个危险的空操作。如果你确实需要捕获所有异常并继续运行（比如在一个长期运行的服务的主循环中），至少应该记录日志。

   try { processRequest(); } catch (...) { logError("Unknown exception in processRequest"); // 可能还需要进行一些必要的状态恢复 }

5.3 异常处理的性能开销分析

很多人对异常的性能有误解，认为“有异常慢，无异常快”。实际情况更复杂：

• “零开销”原则：在没有异常抛出的正常执行路径上，现代C++编译器的异常机制开销极低，甚至接近于零。编译器使用“表驱动”的方法，将异常处理信息放在单独的数据段，不影响正常代码的性能。
• 抛出异常的开销大：抛出和捕获异常是一个相对昂贵的操作。它涉及查找异常处理表、栈展开、异常对象的拷贝/移动等。因此，异常只应用于真正的“异常”情况，而不是常规控制流。
• noexcept的优化：声明函数为noexcept不仅是一种承诺，也允许编译器在调用该函数时进行更多优化（例如，简化栈帧布局）。同时，它影响标准库容器对元素类型的操作选择（如移动 vs 拷贝）。

性能建议：

• 不要因为害怕性能而拒绝使用异常。对于真正的错误情况，异常提供的清晰错误传播路径和自动资源清理的价值远大于其开销。
• 避免在性能关键的紧密循环（hot loop）内部使用可能频繁抛异常的代码。
• 积极使用noexcept来标记那些确实不会失败的函数，帮助编译器和标准库进行优化。

6. 实战：在典型C++场景中应用异常处理

理论最终要服务于实践。我们看几个结合热词的典型场景。

6.1 在资源管理类中实现强异常安全保证

假设我们要实现一个简单的DatabaseConnectionRAII类。

#include <memory> #include <stdexcept> class DatabaseConnection { struct Impl; // 前向声明，Pimpl惯用法 std::unique_ptr<Impl> pImpl_; public: // 构造函数可能因连接失败而抛出异常 DatabaseConnection(const std::string& connectionString); // 析构函数必须noexcept，确保连接被安全关闭 ~DatabaseConnection() noexcept; // 移动操作应设为noexcept，使该类能在标准容器中高效移动 DatabaseConnection(DatabaseConnection&&) noexcept = default; DatabaseConnection& operator=(DatabaseConnection&&) noexcept = default; // 拷贝操作可能被禁用或深拷贝（可能抛出） DatabaseConnection(const DatabaseConnection&) = delete; DatabaseConnection& operator=(const DatabaseConnection&) = delete; void executeQuery(const std::string& sql); // 可能抛出 std::runtime_error // ... 其他方法 };

在这个设计中，构造函数和executeQuery可能抛出异常报告错误。析构函数和移动操作被标记为noexcept，确保了在容器重组或异常发生时资源管理的可靠性。使用std::unique_ptr管理实现细节，即使DatabaseConnection构造中途失败，已分配的资源也能自动释放。

6.2 处理标准库容器操作中的异常

标准库容器本身提供了基本的异常安全保证。以std::vector::push_back为例：

• 如果元素类型的拷贝/移动构造函数是noexcept的，push_back通常提供强保证。
• 如果拷贝/移动构造函数可能抛出，push_back在因容量不足需要重新分配时，只提供基本保证（元素本身可能被拷贝/移动，如果中途失败，已操作的元素状态是有效的，但容器的内容可能部分改变）。

了解这一点很重要。如果你需要向容器中插入一个可能抛出拷贝异常的对象，并且需要强保证，可以考虑先reserve足够空间，或者使用emplace_back配合移动语义（如果移动是noexcept的）。

std::vector<MyType> vec; vec.reserve(100); // 预先分配，避免插入时的重分配 for (int i = 0; i < 100; ++i) { MyType obj = createMyType(i); // 可能失败 vec.push_back(std::move(obj)); // 如果MyType的移动构造是noexcept，这里就是强保证 }

6.3 在多线程与异步编程中传递异常

结合c++多线程和std::async/std::future。

#include <future> #include <iostream> #include <numeric> #include <vector> int computeSum(const std::vector<int>& data) { if (data.empty()) { throw std::invalid_argument("Input vector is empty"); } return std::accumulate(data.begin(), data.end(), 0); } int main() { std::vector<int> bigData = {1, 2, 3, 4, 5}; // 使用 std::async 异步执行计算 std::future<int> fut = std::async(std::launch::async, computeSum, std::cref(bigData)); try { int result = fut.get(); // 如果异步任务中抛出了异常，会在这里被重新抛出 std::cout << "Sum is: " << result << std::endl; } catch (const std::invalid_argument& e) { std::cerr << "Invalid argument: " << e.what() << std::endl; } catch (const std::exception& e) { std::cerr << "Standard exception: " << e.what() << std::endl; } return 0; }

future::get()是获取异步操作结果和异常的统一接口，这使得多线程中的错误处理可以和单线程一样清晰。

6.4 自定义异常类与错误码的混合使用

在一些需要与C接口交互或性能极其敏感的模块，错误码可能更合适。我们可以设计一个系统，在底层使用错误码，在接口边界转换为异常，提供统一的错误处理体验。

enum class DatabaseErrorCode { Success = 0, ConnectionFailed, QueryFailed, Timeout }; class DatabaseException : public std::runtime_error { public: DatabaseException(DatabaseErrorCode code, const std::string& msg) : std::runtime_error(msg), errorCode_(code) {} DatabaseErrorCode getErrorCode() const { return errorCode_; } static void throwIfError(DatabaseErrorCode code, const std::string& context) { if (code != DatabaseErrorCode::Success) { throw DatabaseException(code, "Operation failed: " + context); } } private: DatabaseErrorCode errorCode_; }; // 底层C风格函数 extern "C" DatabaseErrorCode db_query_raw(void* conn, const char* sql); // C++包装层 void executeQueryWrapper(void* connection, const std::string& sql) { DatabaseErrorCode err = db_query_raw(connection, sql.c_str()); DatabaseException::throwIfError(err, "Executing SQL: " + sql); }

这套机制既保留了底层使用轻量级错误码的灵活性，又为上层C++用户提供了方便的基于异常的接口。在实际项目中，异常和错误码并非对立，而是可以根据场景混合使用的工具。