010 《C++ 异常处理 (Exception Handling) 深度解析》
🌟🌟🌟本文由Gemini 2.0 Flash Thinking Experimental 01-21生成，用来辅助学习。🌟🌟🌟
书籍大纲
▮▮ 1. 初识异常处理 (Introduction to Exception Handling)
▮▮▮▮ 1.1 什么是异常？(What is an Exception?)
▮▮▮▮▮▮ 1.1.1 错误与异常的概念辨析 (Distinguishing Errors from Exceptions)
▮▮▮▮▮▮ 1.1.2 异常处理的目的和优势 (Purpose and Advantages of Exception Handling)
▮▮▮▮▮▮ 1.1.3 C++ 异常处理机制概述 (Overview of C++ Exception Handling Mechanism)
▮▮▮▮ 1.2 为什么需要异常处理？(Why Exception Handling is Necessary?)
▮▮▮▮▮▮ 1.2.1 传统错误处理的局限性 (Limitations of Traditional Error Handling)
▮▮▮▮▮▮ 1.2.2 异常处理在复杂系统中的作用 (Role of Exception Handling in Complex Systems)
▮▮▮▮▮▮ 1.2.3 异常处理与代码可读性和维护性 (Exception Handling and Code Readability & Maintainability)
▮▮▮▮ 1.3 异常处理的基本语法：try, catch, throw (Basic Syntax: try, catch, throw)
▮▮▮▮▮▮ 1.3.1 try 块：监控异常 (The try Block: Monitoring for Exceptions)
▮▮▮▮▮▮ 1.3.2 catch 块：捕获和处理异常 (The catch Block: Catching and Handling Exceptions)
▮▮▮▮▮▮ 1.3.3 throw 表达式：抛出异常 (The throw Expression: Throwing Exceptions)
▮▮▮▮▮▮ 1.3.4 异常处理流程详解 (Detailed Exception Handling Flow)
▮▮ 2. 深入 catch 子句：异常的捕获与处理 (深入 catch Clause: Catching and Handling Exceptions)
▮▮▮▮ 2.1 捕获特定类型的异常 (Catching Specific Exception Types)
▮▮▮▮▮▮ 2.1.1 按类型捕获 (Catch by Type)
▮▮▮▮▮▮ 2.1.2 按引用捕获 (Catch by Reference)
▮▮▮▮▮▮ 2.1.3 按常量引用捕获 (Catch by Const Reference)
▮▮▮▮ 2.2 捕获所有异常：省略号 ... (Catching All Exceptions: Ellipsis ...)
▮▮▮▮▮▮ 2.2.1 catch(...) 的语法和用法 (catch(...) Syntax and Usage)
▮▮▮▮▮▮ 2.2.2 catch(...) 的适用场景和局限性 (Use Cases and Limitations of catch(...))
▮▮▮▮▮▮ 2.2.3 重新抛出异常：throw; (Re-throwing Exceptions: throw;)
▮▮▮▮ 2.3 多重 catch 子句与异常类型匹配 (Multiple catch Clauses and Exception Type Matching)
▮▮▮▮▮▮ 2.3.1 顺序匹配原则 (Sequential Matching Principle)
▮▮▮▮▮▮ 2.3.2 异常类型转换与继承关系 (Exception Type Conversion and Inheritance)
▮▮▮▮▮▮ 2.3.3 最佳实践：组织多重 catch 子句 (Best Practices: Organizing Multiple catch Clauses)
▮▮ 3. 异常规范与 noexcept (Exception Specifications and noexcept)
▮▮▮▮ 3.1 动态异常规范 (Dynamic Exception Specifications) [已废弃] (Deprecated Dynamic Exception Specifications)
▮▮▮▮▮▮ 3.1.1 动态异常规范的语法和示例 (Syntax and Examples of Dynamic Exception Specifications)
▮▮▮▮▮▮ 3.1.2 动态异常规范的问题与废弃 (Problems and Deprecation of Dynamic Exception Specifications)
▮▮▮▮ 3.2 noexcept 说明符 (The noexcept Specifier)
▮▮▮▮▮▮ 3.2.1 noexcept 的语法和用法 (noexcept Syntax and Usage)
▮▮▮▮▮▮ 3.2.2 noexcept 的两种形式：无条件与有条件 (Unconditional and Conditional noexcept)
▮▮▮▮▮▮ 3.2.3 noexcept 与性能优化 (Performance Optimization with noexcept)
▮▮▮▮▮▮ 3.2.4 noexcept 与异常安全 (Exception Safety with noexcept)
▮▮▮▮ 3.3 何时使用 noexcept？(When to Use noexcept?)
▮▮▮▮▮▮ 3.3.1 默认应该使用 noexcept 的情况 (Default Cases for Using noexcept)
▮▮▮▮▮▮ 3.3.2 不应该使用 noexcept 的情况 (Cases Against Using noexcept)
▮▮▮▮▮▮ 3.3.3 在接口设计中考虑 noexcept (Considering noexcept in Interface Design)
▮▮ 4. 异常对象与异常类体系 (Exception Objects and Exception Class Hierarchy)
▮▮▮▮ 4.1 标准异常类体系 (Standard Exception Class Hierarchy)
▮▮▮▮▮▮ 4.1.1 std::exception 基类 (std::exception Base Class)
▮▮▮▮▮▮ 4.1.2 逻辑错误类 (std::logic_error Family)
▮▮▮▮▮▮ 4.1.3 运行时错误类 (std::runtime_error Family)
▮▮▮▮▮▮ 4.1.4 其他标准异常类 (Other Standard Exception Classes)
▮▮▮▮ 4.2 自定义异常类的设计 (Designing Custom Exception Classes)
▮▮▮▮▮▮ 4.2.1 继承自 std::exception (Inheriting from std::exception)
▮▮▮▮▮▮ 4.2.2 添加额外的错误信息 (Adding Extra Error Information)
▮▮▮▮▮▮ 4.2.3 提供有意义的 what() 方法 (Providing a Meaningful what() Method)
▮▮▮▮▮▮ 4.2.4 异常类的设计原则 (Design Principles for Exception Classes)
▮▮▮▮ 4.3 异常对象的生命周期与传递 (Lifetime and Propagation of Exception Objects)
▮▮▮▮▮▮ 4.3.1 异常对象的构造与析构 (Construction and Destruction of Exception Objects)
▮▮▮▮▮▮ 4.3.2 栈展开 (Stack Unwinding)
▮▮▮▮▮▮ 4.3.3 异常的传播与未捕获异常 (Exception Propagation and Uncaught Exceptions)
▮▮ 5. RAII 与异常安全编程 (RAII and Exception-Safe Programming)
▮▮▮▮ 5.1 RAII 惯用法详解 (Detailed Explanation of RAII Idiom)
▮▮▮▮▮▮ 5.1.1 RAII 的概念和原理 (Concept and Principles of RAII)
▮▮▮▮▮▮ 5.1.2 RAII 的优势：自动资源管理 (Advantages of RAII: Automatic Resource Management)
▮▮▮▮▮▮ 5.1.3 实现 RAII 的关键：构造函数和析构函数 (Key to RAII: Constructors and Destructors)
▮▮▮▮▮▮ 5.1.4 RAII 的应用示例 (Examples of RAII Applications)
▮▮▮▮ 5.2 异常安全级别 (Exception Safety Levels)
▮▮▮▮▮▮ 5.2.1 不提供保证 (No Guarantee)
▮▮▮▮▮▮ 5.2.2 基本保证 (Basic Guarantee)
▮▮▮▮▮▮ 5.2.3 强异常安全保证 (Strong Exception Safety Guarantee)
▮▮▮▮▮▮ 5.2.4 无异常保证 (No-throw Guarantee)
▮▮▮▮ 5.3 编写异常安全代码的实践 (Practices for Writing Exception-Safe Code)
▮▮▮▮▮▮ 5.3.1 使用 RAII 管理所有资源 (Using RAII to Manage All Resources)
▮▮▮▮▮▮ 5.3.2 避免在析构函数中抛出异常 (Avoiding Exceptions in Destructors)
▮▮▮▮▮▮ 5.3.3 Copy-and-Swap 惯用法 (Copy-and-Swap Idiom)
▮▮▮▮▮▮ 5.3.4 异常安全函数的设计原则 (Design Principles for Exception-Safe Functions)
▮▮ 6. 异常处理的最佳实践 (Best Practices for Exception Handling)
▮▮▮▮ 6.1 何时使用异常？何时使用错误码？(When to Use Exceptions? When to Use Error Codes?)
▮▮▮▮▮▮ 6.1.1 异常的适用场景 (Use Cases for Exceptions)
▮▮▮▮▮▮ 6.1.2 错误码的适用场景 (Use Cases for Error Codes)
▮▮▮▮▮▮ 6.1.3 混合使用异常和错误码 (Mixing Exceptions and Error Codes)
▮▮▮▮ 6.2 异常处理的性能考量 (Performance Considerations of Exception Handling)
▮▮▮▮▮▮ 6.2.1 try-catch 块的运行时开销 (Runtime Overhead of try-catch Blocks)
▮▮▮▮▮▮ 6.2.2 异常抛出和捕获的性能开销 (Performance Overhead of Throwing and Catching Exceptions)
▮▮▮▮▮▮ 6.2.3 优化异常处理性能的技巧 (Techniques for Optimizing Exception Handling Performance)
▮▮▮▮ 6.3 异常处理的代码风格建议 (Code Style Recommendations for Exception Handling)
▮▮▮▮▮▮ 6.3.1 异常类的命名规范 (Naming Conventions for Exception Classes)
▮▮▮▮▮▮ 6.3.2 异常信息的描述 (Describing Exception Information)
▮▮▮▮▮▮ 6.3.3 catch 块的处理逻辑 (Handling Logic in catch Blocks)
▮▮▮▮▮▮ 6.3.4 提高代码的可读性和维护性 (Improving Code Readability and Maintainability)
▮▮ 7. 高级异常处理技巧 (Advanced Exception Handling Techniques)
▮▮▮▮ 7.1 嵌套异常 (Nested Exceptions)
▮▮▮▮▮▮ 7.1.1 什么是嵌套异常？(What are Nested Exceptions?)
▮▮▮▮▮▮ 7.1.2 std::nested_exception 和 std::current_exception() ( std::nested_exception and std::current_exception() )
▮▮▮▮▮▮ 7.1.3 处理嵌套异常的示例 (Examples of Handling Nested Exceptions)
▮▮▮▮ 7.2 异常转换 (Exception Translation)
▮▮▮▮▮▮ 7.2.1 异常转换的应用场景 (Use Cases for Exception Translation)
▮▮▮▮▮▮ 7.2.2 实现异常转换的方法 (Methods for Implementing Exception Translation)
▮▮▮▮▮▮ 7.2.3 异常转换的示例 (Examples of Exception Translation)
▮▮▮▮ 7.3 多线程环境下的异常处理 (Exception Handling in Multithreaded Environments)
▮▮▮▮▮▮ 7.3.1 线程间异常的传播 (Exception Propagation Between Threads)
▮▮▮▮▮▮ 7.3.2 线程局部存储与异常安全 (Thread-Local Storage and Exception Safety)
▮▮▮▮▮▮ 7.3.3 异步异常处理 (Asynchronous Exception Handling)
▮▮ 8. 案例分析与实战 (Case Studies and Practical Applications)
▮▮▮▮ 8.1 文件操作中的异常处理 (Exception Handling in File Operations)
▮▮▮▮▮▮ 8.1.1 文件打开异常 (File Open Exceptions)
▮▮▮▮▮▮ 8.1.2 文件读写异常 (File Read/Write Exceptions)
▮▮▮▮▮▮ 8.1.3 文件关闭与资源清理 (File Closing and Resource Cleanup)
▮▮▮▮▮▮ 8.1.4 案例：异常安全的文件读写类 (Case Study: Exception-Safe File Read/Write Class)
▮▮▮▮ 8.2 网络编程中的异常处理 (Exception Handling in Network Programming)
▮▮▮▮▮▮ 8.2.1 网络连接异常 (Network Connection Exceptions)
▮▮▮▮▮▮ 8.2.2 数据传输异常 (Data Transmission Exceptions)
▮▮▮▮▮▮ 8.2.3 套接字资源管理 (Socket Resource Management)
▮▮▮▮▮▮ 8.2.4 案例：异常安全的网络客户端 (Case Study: Exception-Safe Network Client)
▮▮▮▮ 8.3 数据库操作中的异常处理 (Exception Handling in Database Operations)
▮▮▮▮▮▮ 8.3.1 数据库连接异常 (Database Connection Exceptions)
▮▮▮▮▮▮ 8.3.2 SQL 执行异常 (SQL Execution Exceptions)
▮▮▮▮▮▮ 8.3.3 事务处理与异常回滚 (Transaction Handling and Exception Rollback)
▮▮▮▮▮▮ 8.3.4 案例：异常安全的数据库操作类 (Case Study: Exception-Safe Database Operation Class)
▮▮ 9. 现代 C++ 异常处理的新特性 (New Features in Modern C++ Exception Handling)
▮▮▮▮ 9.1 noexcept 的增强 (Enhancements to noexcept)
▮▮▮▮▮▮ 9.1.1 条件 noexcept 的扩展应用 (Expanded Applications of Conditional noexcept)
▮▮▮▮▮▮ 9.1.2 noexcept 与移动语义的深入结合 (Deeper Integration of noexcept and Move Semantics)
▮▮▮▮ 9.2 异常指针：std::exception_ptr (Exception Pointers: std::exception_ptr)
▮▮▮▮▮▮ 9.2.1 std::exception_ptr 的概念和用途 (Concept and Purpose of std::exception_ptr)
▮▮▮▮▮▮ 9.2.2 std::current_exception() 和 std::rethrow_exception() (std::current_exception() and std::rethrow_exception())
▮▮▮▮▮▮ 9.2.3 std::make_exception_ptr() ( std::make_exception_ptr() )
▮▮▮▮▮▮ 9.2.4 异步操作中的异常传递 (Exception Propagation in Asynchronous Operations)
▮▮▮▮ 9.3 其他现代 C++ 异常处理特性 (Other Modern C++ Exception Handling Features)
▮▮▮▮▮▮ 9.3.1 std::terminate_handler 和 std::set_terminate() (std::terminate_handler and std::set_terminate())
▮▮▮▮▮▮ 9.3.2 std::unexpected_handler 和 std::set_unexpected() [已废弃] (std::unexpected_handler and std::set_unexpected() [Deprecated])
▮▮ 附录A: 附录 A：C++ 标准异常类层次结构 (Appendix A: C++ Standard Exception Class Hierarchy)
▮▮ 附录B: 附录 B：常见异常处理陷阱与解决方案 (Appendix B: Common Exception Handling Pitfalls and Solutions)
▮▮ 附录C: 附录 C：C++ 异常安全级别速查表 (Appendix C: C++ Exception Safety Level Cheat Sheet)
▮▮ 附录D: 参考文献 (References)
1. 初识异常处理 (Introduction to Exception Handling)
1.1 什么是异常？(What is an Exception?)
在软件开发过程中，程序难免会遇到各种各样的问题。这些问题可以大致分为两类：错误 (Error) 和 异常 (Exception)。理解这两者之间的区别，以及异常在程序运行中的角色，是掌握异常处理机制的基础。
1.1.1 错误与异常的概念辨析 (Distinguishing Errors from Exceptions)
错误 (Error) 通常指的是系统级别的、不可恢复的严重问题。例如，内存耗尽 (Out of Memory)、栈溢出 (Stack Overflow)、硬件故障 (Hardware Failure) 等。这类错误通常超出了程序自身的控制能力，一旦发生，程序往往无法继续正常运行，甚至可能导致程序崩溃。错误通常表明系统或环境出现了根本性的问题，需要程序外部的力量（例如，重启系统、增加内存等）才能解决。
异常 (Exception) 则指的是程序运行过程中出现的意外情况或不正常状态，但这些情况通常是可以预见和处理的。例如，文件未找到 (File Not Found)、网络连接中断 (Network Connection Lost)、除零错误 (Division by Zero)、数组越界 (Array Out of Bounds)、无效的输入数据 (Invalid Input Data) 等。异常通常是程序逻辑或运行时环境的特定问题，通过合理的异常处理 (Exception Handling) 机制，程序可以在遇到异常时进行适当的处理，例如，清理资源 (Resource Cleanup)、记录日志 (Logging)、提示用户 (User Notification)，甚至尝试恢复 (Recovery) 并继续执行，而不是立即终止程序。
简而言之：
⚝ 错误 (Error)：通常是严重的、系统级的、不可恢复的问题，程序自身难以处理。
⚝ 异常 (Exception)：通常是运行时的、可预见的、可以处理的意外情况，程序可以通过异常处理机制进行应对。
在 C++ 异常处理的语境下，我们主要关注的是运行时异常 (Runtime Exceptions)。C++ 的异常处理机制，如 try-catch-throw 语句，正是为了优雅地处理这类运行时异常而设计的。通过异常处理，我们可以编写更健壮、更可靠的程序，即使在遇到意外情况时，也能保持程序的稳定性和用户体验。
1.1.2 异常处理的目的和优势 (Purpose and Advantages of Exception Handling)
异常处理机制的引入，旨在解决传统错误处理方法的一些固有缺陷，并为软件开发带来诸多优势。其主要目的和优势包括：
① 提高程序的健壮性 (Robustness)：
▮▮▮▮ⓑ 异常处理允许程序在遇到意外情况时，不会立即崩溃，而是有机会进行优雅地处理，例如，回滚操作 (Rollback Operation)、资源释放 (Resource Release)，从而避免程序进入不确定状态，增强程序的容错能力 (Fault Tolerance)。
▮▮▮▮ⓒ 通过预先设计异常处理逻辑，可以有效地隔离错误 (Error Isolation)，防止错误扩散到程序的其他部分，提高程序的稳定性 (Stability)。
② 改善代码的可维护性 (Maintainability)：
▮▮▮▮ⓑ 传统的错误处理方式（如错误码、返回值检查）常常将错误处理代码与正常的业务逻辑代码混杂在一起，使得代码可读性差 (Poor Readability)，难以理解 (Difficult to Understand) 和 维护 (Maintain)。
▮▮▮▮ⓒ 异常处理机制将错误处理代码 (Error Handling Code) 从正常业务逻辑代码 (Normal Business Logic Code) 中分离出来 (Separation of Concerns)，使得代码结构更清晰，逻辑更简洁，提高了代码的可维护性 (Maintainability)。开发人员可以更专注于业务逻辑的实现，而将异常处理放在专门的 catch 块中。
③ 增强代码的可读性 (Readability)：
▮▮▮▮ⓑ 使用异常处理，可以使代码的控制流 (Control Flow) 更加自然和线性。正常的程序流程不会被大量的错误检查代码打断，代码更易于阅读和理解。
▮▮▮▮ⓒ 异常处理可以提供更丰富 (Rich) 和 明确 (Explicit) 的错误信息。异常对象可以携带关于错误类型、错误发生位置等详细信息，有助于快速定位和解决问题。
④ 简化复杂的错误处理逻辑 (Simplify Complex Error Handling Logic)：
▮▮▮▮ⓑ 在复杂的程序中，错误可能发生在多层函数调用链的深处。传统的错误码传递方式需要层层检查和传递错误码，代码冗余且容易出错。
▮▮▮▮ⓒ 异常可以直接抛出 (Throw) 到调用栈的上层，由合适的 catch 块进行处理，无需中间函数层层传递错误信息，简化了错误处理的流程。
⑤ 支持构造函数和析构函数的错误处理 (Error Handling in Constructors and Destructors)：
▮▮▮▮ⓑ 构造函数和析构函数没有返回值，传统的错误码返回方式无法应用于构造函数和析构函数的错误处理。
▮▮▮▮ⓒ 异常处理机制为构造函数和析构函数提供了唯一的错误报告机制 (Error Reporting Mechanism)。当构造对象失败时，可以抛出异常；当析构资源失败时，虽然不建议在析构函数中抛出异常，但异常处理机制仍然是处理析构函数可能遇到的问题的关键考虑因素。
综上所述，异常处理机制是现代软件开发中不可或缺的一部分。它不仅提高了程序的质量 (Quality) 和 可靠性 (Reliability)，也提升了开发效率和代码的可维护性。
1.1.3 C++ 异常处理机制概述 (Overview of C++ Exception Handling Mechanism)
C++ 异常处理机制主要由三个关键字组成：try、catch 和 throw。它们共同协作，构成了 C++ 异常处理的基本框架。
⚝ try 块 (try block)：try 块用于监控 (Monitor) 可能抛出异常的代码块。我们将可能产生异常的代码放置在 try 块内部。如果 try 块中的代码在执行过程中抛出了异常，程序的控制权将立即转移到与之匹配的 catch 块。
⚝ catch 块 (catch block)：catch 块用于捕获 (Catch) 和 处理 (Handle) 在 try 块中抛出的异常。catch 块紧跟在 try 块之后，可以有一个或多个 catch 块。每个 catch 块声明它可以处理的异常类型 (Exception Type)。当 try 块中抛出的异常类型与某个 catch 块声明的异常类型匹配 (Match) 时，该 catch 块将被执行，负责处理该类型的异常。
⚝ throw 表达式 (throw expression)：throw 表达式用于抛出 (Throw) 异常。当程序在运行过程中检测到异常情况时，可以使用 throw 表达式创建一个异常对象 (Exception Object) 并抛出。抛出的异常对象的类型决定了哪个 catch 块可以捕获并处理该异常。
基本语法结构 如下：
1
try {
2
// 可能会抛出异常的代码 (Code that might throw exceptions)
3
// ...
4
throw exception_object; // 抛出异常 (Throw an exception)
5
// ...
6
}
7
catch (exception_type1 exception_variable1) {
8
// 处理 exception_type1 类型的异常 (Handle exceptions of type exception_type1)
9
// ...
10
}
11
catch (exception_type2 exception_variable2) {
12
// 处理 exception_type2 类型的异常 (Handle exceptions of type exception_type2)
13
// ...
14
}
15
catch (...) { // 捕获所有其他类型的异常 (Catch all other types of exceptions)
16
// 通用异常处理 (Generic exception handling)
17
// ...
18
}
19
// try-catch 块之后的代码，程序将继续执行 (Code after the try-catch block, program execution continues)
异常处理流程 简述如下：
- 程序执行到
try块，开始监控try块内的代码。 - 如果在
try块内的代码执行过程中，没有抛出异常，则程序顺序执行 (Sequentially Execute)try块中的代码，然后跳过 (Skip) 后面的所有catch块，继续执行try-catch块之后的代码。 - 如果在
try块内的代码执行过程中，抛出了一个异常，例如通过throw表达式抛出，则程序会立即停止 (Immediately Stop) 执行try块中剩余的代码，并开始查找与之匹配 (Matching) 的catch块。 - 程序会按照
catch块在代码中出现的顺序，依次检查 (Sequentially Check) 每个catch块声明的异常类型。 - 如果找到一个
catch块，其声明的异常类型与抛出的异常类型匹配 (Match)（或为基类关系，后续章节会详细介绍），则程序会将控制权转移到该catch块，执行catch块内的异常处理代码。 - 如果所有的
catch块都无法匹配抛出的异常类型，则异常会传播 (Propagate) 到调用栈 (Call Stack) 的上一层。这个过程称为 栈展开 (Stack Unwinding)，后续章节会详细介绍。如果在整个调用栈中都没有找到合适的catch块来处理该异常，则程序会调用std::terminate()函数，通常会导致程序异常终止 (Abnormal Termination)。 - 如果找到了匹配的
catch块并成功处理了异常，则程序会继续执行 (Continue Execution)try-catch块之后的代码，仿佛异常从未发生过一样。
C++ 异常处理机制的核心思想是：将异常的检测和处理分离 (Separation of Exception Detection and Handling)。try 块负责检测异常，catch 块负责处理异常。这种分离使得代码结构更清晰，错误处理更集中，程序更健壮。
1.2 为什么需要异常处理？(Why Exception Handling is Necessary?)
传统的错误处理方法在某些情况下显得力不从心，尤其是在面对复杂系统和需要高可靠性的应用时。异常处理的出现，正是为了弥补传统方法的不足，提供一种更有效、更优雅的错误管理方案。
1.2.1 传统错误处理的局限性 (Limitations of Traditional Error Handling)
传统的错误处理方法，例如使用错误码 (Error Codes)、返回值检查 (Return Value Checks)、全局错误标志 (Global Error Flags) 等，在很多情况下存在明显的局限性：
① 代码冗余 (Code Redundancy)：
▮▮▮▮ⓑ 传统的错误处理方法需要在每个可能出错的函数调用之后都进行错误检查。例如，在使用错误码时，每个函数调用后都需要检查返回值是否为错误码，这导致代码中充斥着大量的 if-else 错误检查代码，代码臃肿 (Code Bloating)，可读性下降 (Reduced Readability)。
1
// 传统错误码示例 (Traditional Error Code Example)
2
int result = function_that_might_fail();
3
if (result == ERROR_CODE_1) {
4
// 处理错误 1 (Handle Error 1)
5
// ...
6
} else if (result == ERROR_CODE_2) {
7
// 处理错误 2 (Handle Error 2)
8
// ...
9
} else if (result != SUCCESS) {
10
// 处理其他错误 (Handle Other Errors)
11
// ...
12
} else {
13
// 正常执行 (Normal Execution)
14
// ...
15
}
▮▮▮▮ⓑ 这种错误检查代码与正常的业务逻辑代码交织在一起 (Intertwined)，使得代码逻辑混乱，难以维护。
② 错误容易被忽略 (Errors Easily Ignored)：
▮▮▮▮ⓑ 由于错误检查代码的冗余和繁琐，开发人员可能会疏忽 (Neglect) 错误检查，或者为了简化代码而有意忽略 (Intentionally Ignore) 错误检查。
▮▮▮▮ⓒ 例如，在使用返回值检查时，如果函数返回错误码，但调用者没有检查返回值，程序仍然会继续执行，但此时程序可能处于错误状态 (Error State)，潜在的错误可能会被延迟 (Delayed) 到后续的执行过程中才暴露出来，增加了调试难度。
1
// 错误容易被忽略的示例 (Example of Errors Easily Ignored)
2
function_that_might_fail(); // 忘记检查返回值 (Forgot to check the return value)
3
// ... 程序继续执行，但可能处于错误状态 (Program continues execution, but might be in an error state)
③ 错误信息有限 (Limited Error Information)：
▮▮▮▮ⓑ 传统的错误码通常只能表示错误类型 (Error Type)，而缺乏 (Lack of) 关于错误发生的具体位置 (Specific Location)、上下文信息 (Context Information) 等详细信息，不利于错误诊断和调试。
▮▮▮▮ⓒ 全局错误标志虽然可以提供一些额外信息，但容易被覆盖 (Overwritten)，且在多线程环境下可能存在线程安全问题 (Thread Safety Issues)。
④ 难以处理构造函数和析构函数的错误 (Difficult to Handle Errors in Constructors and Destructors)：
▮▮▮▮ⓑ 构造函数和析构函数没有返回值，传统的返回值检查方法不适用于 (Not Applicable) 构造函数和析构函数的错误处理。
▮▮▮▮ⓒ 当构造对象失败时，传统的错误处理方法难以有效地通知调用者。虽然可以使用一些技巧，例如使用工厂函数 (Factory Function) 或 两阶段构造 (Two-Phase Construction)，但这增加了代码的复杂性。
▮▮▮▮ⓓ 析构函数中的错误处理也比较棘手，因为在析构函数中抛出异常通常被认为是不安全的。
⑤ 函数签名复杂化 (Complicated Function Signatures)：
▮▮▮▮ⓑ 为了传递错误信息，函数签名可能需要额外包含错误码参数或返回错误码，使得函数签名复杂化 (Complicated)，降低了代码的清晰度 (Clarity)。
1
// 函数签名复杂化的示例 (Example of Complicated Function Signature)
2
int function_that_might_fail(int input, int* output, ErrorCode* error); // 需要额外的 ErrorCode* 参数 (Needs an extra ErrorCode* parameter)
⑥ 难以跨越函数边界传递错误信息 (Difficult to Propagate Error Information Across Function Boundaries)：
▮▮▮▮ⓑ 当错误发生在深层嵌套的函数调用链中时，传统的错误码需要通过返回值 (Return Value) 或 输出参数 (Output Parameter) 层层传递到调用栈的上层，代码繁琐且容易出错。
1
// 错误信息层层传递的示例 (Example of Error Information Propagating Layer by Layer)
2
ErrorCode func1() {
3
ErrorCode err = func2();
4
if (err != SUCCESS) return err;
5
// ...
6
return SUCCESS;
7
}
8
9
ErrorCode func2() {
10
ErrorCode err = func3();
11
if (err != SUCCESS) return err;
12
// ...
13
return SUCCESS;
14
}
15
16
ErrorCode func3() {
17
// ...
18
if (/* 发生错误 */) {
19
return ERROR_CODE_X;
20
}
21
return SUCCESS;
22
}
相比之下，异常处理机制可以有效地克服这些局限性，提供更强大、更灵活、更易用的错误管理方案。
1.2.2 异常处理在复杂系统中的作用 (Role of Exception Handling in Complex Systems)
在大型、复杂的软件系统中，错误处理变得尤为重要。异常处理机制在复杂系统中发挥着至关重要的作用：
① 错误隔离 (Error Isolation)：
▮▮▮▮ⓑ 复杂系统通常由多个模块、组件、子系统组成，模块之间相互依赖，错误可能在一个模块中发生，但如果处理不当，可能会蔓延 (Spread) 到其他模块，甚至导致整个系统崩溃。
▮▮▮▮ⓒ 异常处理机制可以有效地隔离错误 (Isolate Errors)。当一个模块发生异常时，异常会被限制在该模块的 try-catch 块范围内，不会直接影响到其他模块的正常运行。通过在模块边界设置 try-catch 块，可以构建容错边界 (Fault Tolerance Boundary)，防止错误扩散。
② 提高系统稳定性 (System Stability)：
▮▮▮▮ⓑ 复杂系统更容易出现各种意外情况，例如，资源竞争 (Resource Contention)、外部依赖失效 (External Dependency Failure)、并发冲突 (Concurrency Conflict) 等。
▮▮▮▮ⓒ 异常处理机制允许系统在遇到这些意外情况时，能够优雅地处理 (Gracefully Handle)，例如，降级服务 (Degrade Service)、切换备用方案 (Switch to Backup Plan)、重试操作 (Retry Operation) 等，而不是立即崩溃。这大大提高了系统的稳定性和可用性 (Stability and Availability)。
③ 简化错误处理流程 (Simplified Error Handling Flow)：
▮▮▮▮ⓑ 复杂系统通常具有深层嵌套的调用链 (Deeply Nested Call Chains)。传统的错误码传递方式需要在多层函数之间层层传递错误码，代码复杂且容易出错。
▮▮▮▮ⓒ 异常可以直接抛出 (Directly Thrown) 到调用栈的上层，由合适的 catch 块集中处理，无需中间函数层层传递错误信息，简化了错误处理的流程，降低了代码的复杂性。
④ 支持异步和并发编程 (Support for Asynchronous and Concurrent Programming)：
▮▮▮▮ⓑ 现代复杂系统往往采用异步 (Asynchronous) 和 并发 (Concurrent) 编程模型，以提高系统的吞吐量 (Throughput) 和 响应速度 (Responsiveness)。
▮▮▮▮ⓒ 异常处理机制可以很好地支持异步和并发编程。例如，在多线程程序中，每个线程可以有自己的 try-catch 块，独立处理线程内部的异常，避免线程之间的错误互相影响。C++11 引入的 std::future 和 std::promise 等机制，也提供了在异步操作中传递异常信息的手段。
⑤ 统一的错误处理框架 (Unified Error Handling Framework)：
▮▮▮▮ⓑ 异常处理提供了一种统一 (Unified) 的错误处理框架，可以应用于系统中的各个模块和组件。
▮▮▮▮ⓒ 通过定义标准异常类 (Standard Exception Classes) 和 自定义异常类 (Custom Exception Classes)，可以规范化错误报告和处理方式，提高系统的一致性 (Consistency) 和 可维护性 (Maintainability)。
在构建复杂系统时，合理地运用异常处理机制，是保证系统可靠性 (Reliability)、可维护性 (Maintainability) 和 可扩展性 (Scalability) 的关键因素之一。
1.2.3 异常处理与代码可读性和维护性 (Exception Handling and Code Readability & Maintainability)
异常处理机制不仅提高了程序的健壮性，也显著改善了代码的可读性 (Readability) 和 维护性 (Maintainability)。
① 代码结构更清晰 (Clearer Code Structure)：
▮▮▮▮ⓑ 异常处理将正常业务逻辑代码 (Normal Business Logic Code) 和 错误处理代码 (Error Handling Code) 分离 (Separate) 开来。正常的业务逻辑代码可以专注于实现核心功能，而无需穿插大量的错误检查代码，代码结构更简洁、更清晰。
▮▮▮▮ⓒ try 块明确标示了可能抛出异常的代码范围 (Code Scope that Might Throw Exceptions)，catch 块集中处理特定类型的异常，使得代码的控制流 (Control Flow) 更易于理解和跟踪。
② 错误处理更集中 (Centralized Error Handling)：
▮▮▮▮ⓑ 异常处理允许在调用栈 (Call Stack) 的合适位置集中处理错误。通常，错误应该在能够合理处理 (Reasonably Handle) 该错误的最高层级 (Highest Level) 进行处理。例如，用户界面层可以捕获文件操作异常，并向用户显示友好的错误提示；而底层的文件操作函数只需检测到错误并抛出异常，无需关心如何向用户展示错误信息。
▮▮▮▮ⓒ 集中式的错误处理减少了错误处理代码的分散性 (Dispersion) 和 冗余性 (Redundancy)，提高了代码的可维护性 (Maintainability)。
③ 异常信息更丰富 (Richer Exception Information)：
▮▮▮▮ⓑ 异常对象可以携带类型信息 (Type Information) 和 详细的错误描述信息 (Detailed Error Description)，例如，错误消息字符串、错误代码、错误发生的文件名和行号等。这些信息有助于开发人员快速定位和诊断错误。
▮▮▮▮ⓒ 通过自定义异常类 (Custom Exception Classes)，可以根据应用程序的需求，定义更丰富的异常信息，例如，业务相关的错误代码、上下文数据等。
④ 减少代码嵌套 (Reduced Code Nesting)：
▮▮▮▮ⓑ 传统的错误处理方法，例如使用多层 if-else 嵌套检查错误码，容易导致代码缩进过深 (Excessive Indentation)，逻辑复杂 (Complex Logic)，降低代码的可读性。
▮▮▮▮ⓒ 异常处理机制可以有效地减少代码嵌套 (Reduce Code Nesting)。正常的业务逻辑代码无需嵌套在多层错误检查代码中，代码结构更扁平化，更易于理解。
⑤ 提高代码复用性 (Improved Code Reusability)：
▮▮▮▮ⓑ 异常处理使得函数可以更专注于实现自身的功能，而无需过多地考虑错误处理的细节。函数只需在检测到异常情况时抛出异常，由调用者决定如何处理。这提高了函数的通用性 (Generality) 和 复用性 (Reusability)。
▮▮▮▮ⓒ 基于异常处理的错误管理机制，可以构建更模块化 (Modular) 和 组件化 (Component-based) 的软件系统，提高代码的可维护性 (Maintainability) 和 可扩展性 (Scalability)。
总而言之，异常处理机制通过分离错误处理逻辑 (Separating Error Handling Logic)、集中错误处理 (Centralizing Error Handling)、提供丰富的错误信息 (Providing Rich Error Information) 等方式，显著提高了代码的可读性 (Readability)、可维护性 (Maintainability) 和 可理解性 (Understandability)，使得软件开发更加高效和可靠。
1.3 异常处理的基本语法：try, catch, throw (Basic Syntax: try, catch, throw)
C++ 异常处理的核心在于 try、catch 和 throw 这三个关键字。理解它们的语法和用法，是掌握 C++ 异常处理的基础。
1.3.1 try 块：监控异常 (The try Block: Monitoring for Exceptions)
try 块是异常处理机制的监控区域 (Monitoring Region)。它的作用是标识 (Identify) 一段代码，这段代码中可能抛出异常 (May Throw Exceptions)。try 块以关键字 try 开始，后跟一个用花括号 {} 括起来的代码块。
语法 如下：
1
try {
2
// 可能会抛出异常的代码 (Code that might throw exceptions)
3
// ...
4
}
5
// catch 块 (catch blocks) 通常紧随 try 块之后 (usually follow the try block)
作用：
⚝ 划定监控范围 (Define Monitoring Scope)：try 块划定了异常监控的范围。只有 try 块内部直接或间接调用的代码抛出的异常，才会被后续的 catch 块捕获和处理。try 块外部抛出的异常，不会被该 try 块的 catch 块捕获。
⚝ 激活异常处理机制 (Activate Exception Handling Mechanism)：当程序执行到 try 块时，C++ 异常处理机制被激活 (Activated)。系统会记录当前 try 块的相关信息，以便在 try 块内部抛出异常时，能够找到合适的 catch 块进行处理。
用法示例：
1
#include <iostream>
2
#include <fstream>
3
#include <stdexcept> // 引入标准异常类 (Include standard exception classes)
4
5
int main() {
6
std::ifstream file;
7
try {
8
file.open("non_existent_file.txt"); // 尝试打开文件，可能抛出异常 (Attempt to open a file, might throw exception)
9
if (!file.is_open()) {
10
throw std::runtime_error("Failed to open file"); // 手动抛出异常 (Manually throw an exception)
11
}
12
std::cout << "File opened successfully." << std::endl; // 如果文件打开成功，执行后续操作 (If file opened successfully, perform subsequent operations)
13
// ... 其他文件操作 (Other file operations) ...
14
file.close();
15
}
16
catch (const std::runtime_error& error) { // 捕获 std::runtime_error 类型的异常 (Catch std::runtime_error type exception)
17
std::cerr << "Runtime error: " << error.what() << std::endl; // 输出错误信息 (Output error message)
18
// ... 异常处理代码 (Exception handling code) ...
19
if (file.is_open()) {
20
file.close(); // 确保在异常情况下关闭文件 (Ensure file is closed in case of exception)
21
}
22
return 1; // 返回错误代码 (Return error code)
23
}
24
catch (...) { // 捕获其他所有类型的异常 (Catch all other types of exceptions)
25
std::cerr << "An unexpected error occurred." << std::endl; // 输出通用错误信息 (Output generic error message)
26
if (file.is_open()) {
27
file.close(); // 确保在异常情况下关闭文件 (Ensure file is closed in case of exception)
28
}
29
return 2; // 返回错误代码 (Return error code)
30
}
31
32
std::cout << "Program continues after try-catch block." << std::endl; // 程序在 try-catch 块之后继续执行 (Program continues after try-catch block)
33
return 0; // 程序正常结束 (Program ends normally)
34
}
要点：
⚝ try 块必须与至少一个 (At Least One) catch 块配对使用 (Used in Pairs)。单独的 try 块没有意义，也无法编译通过。
⚝ try 块可以嵌套 (Nested) 使用，即在一个 try 块内部可以包含另一个 try 块。
⚝ try 块内部可以包含任何合法的 C++ 代码，包括函数调用、循环、条件语句等。
⚝ try 块的执行效率几乎没有额外开销 (Little to No Overhead)。只有当 try 块内部抛出异常时，才会产生额外的性能开销，主要来自于 栈展开 (Stack Unwinding) 和 异常对象的构造与析构 (Construction and Destruction of Exception Objects)。在没有异常抛出的情况下，try 块对性能的影响可以忽略不计。
1.3.2 catch 块：捕获和处理异常 (The catch Block: Catching and Handling Exceptions)
catch 块紧跟在 try 块之后，用于捕获 (Catch) 和 处理 (Handle) try 块中抛出的异常。一个 try 块后面可以跟随一个或多个 (One or More) catch 块，每个 catch 块负责处理特定类型 (Specific Type) 的异常。
语法 如下：
1
catch (exception_declaration) {
2
// 异常处理代码 (Exception handling code)
3
// ...
4
}
其中，exception_declaration 是 异常声明 (Exception Declaration)，用于指定 catch 块可以捕获的异常类型。异常声明的语法类似于函数参数声明，通常包含以下部分：
⚝ 异常类型 (Exception Type)：指定 catch 块可以捕获的异常类型。可以是基本数据类型 (Primitive Data Types)（如 int, char*），标准异常类 (Standard Exception Classes)（如 std::runtime_error, std::bad_alloc），自定义异常类 (Custom Exception Classes)，或者省略号 ... (Ellipsis ...) (用于捕获所有类型的异常)。
⚝ 异常变量名 (Exception Variable Name) (可选)：可以为捕获的异常对象指定一个变量名，在 catch 块内部可以使用该变量名访问异常对象，获取异常的详细信息。如果 catch 块不需要访问异常对象，可以省略变量名。
作用：
⚝ 捕获异常 (Catch Exceptions)：catch 块负责捕获 try 块中抛出的异常。当 try 块中抛出的异常类型与某个 catch 块声明的异常类型匹配 (Match) 时，该 catch 块将被执行。
⚝ 处理异常 (Handle Exceptions)：catch 块内部的代码用于处理捕获到的异常。异常处理代码可以包括：
▮▮▮▮⚝ 记录日志 (Logging)：将异常信息记录到日志文件或控制台，以便后续分析和调试。
▮▮▮▮⚝ 资源清理 (Resource Cleanup)：释放 try 块中分配的资源，例如，关闭文件、释放内存、解锁互斥锁等，防止资源泄漏。
▮▮▮▮⚝ 用户提示 (User Notification)：向用户显示友好的错误提示信息，例如，告知用户文件打开失败、网络连接中断等。
▮▮▮▮⚝ 状态恢复 (State Recovery)：尝试将程序状态恢复到安全状态，例如，回滚事务、撤销操作等，使程序能够继续执行。
▮▮▮▮⚝ 重新抛出异常 (Re-throwing Exception)：在 catch 块中可以再次使用 throw 表达式重新抛出当前捕获的异常，或者抛出一个新的异常，将异常传递给调用栈的上层处理。
▮▮▮▮⚝ 忽略异常 (Ignore Exception) (不推荐)：在某些特殊情况下，可以忽略捕获到的异常，但通常不建议这样做，因为这可能会隐藏潜在的问题。
不同类型的 catch 块：
⚝ 捕获特定类型异常的 catch 块 (Catch blocks for specific exception types)：
1
catch (const std::runtime_error& error) { // 捕获 std::runtime_error 类型的异常 (Catch std::runtime_error type exception), 使用常量引用 (using const reference)
2
std::cerr << "Runtime error: " << error.what() << std::endl;
3
// ...
4
}
5
catch (const std::bad_alloc& error) { // 捕获 std::bad_alloc 类型的异常 (Catch std::bad_alloc type exception), 使用常量引用 (using const reference)
6
std::cerr << "Memory allocation failed: " << error.what() << std::endl;
7
// ...
8
}
9
catch (int errorCode) { // 捕获 int 类型的异常 (Catch int type exception), 按值捕获 (catch by value)
10
std::cerr << "Error code: " << errorCode << std::endl;
11
// ...
12
}
13
catch (char* errorMessage) { // 捕获 char* 类型的异常 (Catch char* type exception), 按值捕获 (catch by value)
14
std::cerr << "Error message: " << errorMessage << std::endl;
15
// ...
16
}
▮▮▮▮ⓐ 可以使用按值捕获 (Catch by Value)、按引用捕获 (Catch by Reference) 或 按常量引用捕获 (Catch by Const Reference) 的方式声明 catch 块的异常参数。通常建议使用按引用捕获或按常量引用捕获，特别是对于类类型的异常，可以避免对象切割 (Object Slicing) 和提高效率。
⚝ 捕获所有异常的 catch 块 (Catch block for all exceptions)：
1
catch (...) { // 使用省略号 ... 捕获所有类型的异常 (Using ellipsis ... to catch all types of exceptions)
2
std::cerr << "An unexpected exception occurred." << std::endl; // 通用异常处理 (Generic exception handling)
3
// ...
4
throw; // 可选：重新抛出当前异常 (Optional: re-throw the current exception)
5
}
▮▮▮▮ⓐ 使用 省略号 ... (Ellipsis ...) 作为异常声明的 catch 块，可以捕获所有类型 (All Types) 的异常，包括基本数据类型、标准异常类、自定义异常类，甚至是 C++ 异常处理机制无法识别的异常 (例如，由非 C++ 代码抛出的异常)。
▮▮▮▮ⓑ catch(...) 块通常作为最后的 catch 块 (Last catch block) 出现在 try-catch 块的末尾，用于提供最后的异常处理保障 (Last resort for exception handling)。
▮▮▮▮ⓒ 在 catch(...) 块中，无法访问 (Cannot Access) 捕获到的异常对象，因为不知道异常对象的具体类型。如果需要获取或处理异常对象，应该使用捕获特定类型异常的 catch 块。
▮▮▮▮ⓓ catch(...) 块可以重新抛出 (Re-throw) 当前捕获的异常，使用 throw; 语句（注意，是 throw; 而不是 throw ...; 或 throw exception_variable;）。重新抛出异常会将异常传递给调用栈的上层，由更外层的 try-catch 块进行处理。这在某些情况下很有用，例如，在 catch(...) 块中进行一些通用的清理操作后，将异常传递给上层处理。
要点：
⚝ catch 块必须紧跟在 try 块之后，或者紧跟在另一个 catch 块之后。
⚝ 一个 try 块后面可以有多个 catch 块，用于处理不同类型的异常。catch 块的顺序很重要 (Important)，异常会按照 catch 块在代码中出现的顺序依次匹配 (Sequentially Matched)。通常，应该将更具体 (More Specific) 的异常类型的 catch 块放在前面，将更通用 (More Generic) 的异常类型（例如，基类异常、catch(...)）的 catch 块放在后面。
⚝ 如果没有任何 catch 块能够匹配抛出的异常类型，则异常会传播 (Propagate) 到调用栈的上层。
1.3.3 throw 表达式：抛出异常 (The throw Expression: Throwing Exceptions)
throw 表达式用于抛出 (Throw) 异常。当程序在运行过程中检测到异常情况 (Exceptional Condition) 或 错误状态 (Error State) 时，可以使用 throw 表达式创建一个异常对象 (Exception Object) 并抛出。
语法 如下：
1
throw exception_object;
其中，exception_object 是要抛出的异常对象 (Exception Object)。异常对象可以是任何合法的 C++ 表达式，其结果的类型决定了抛出的异常类型。通常，异常对象是以下类型的实例：
⚝ 基本数据类型 (Primitive Data Types)：例如，int, char*, double 等。虽然可以抛出基本数据类型的异常，但通常不建议 (Not Recommended) 这样做，因为基本数据类型携带的错误信息有限，不利于异常处理和错误诊断。
⚝ 标准异常类 (Standard Exception Classes)：C++ 标准库提供了一系列预定义的异常类，例如，std::exception 及其派生类 std::runtime_error, std::logic_error, std::bad_alloc 等。建议尽可能使用标准异常类来抛出异常，因为标准异常类具有良好的语义 (Semantics) 和 兼容性 (Compatibility)。
⚝ 自定义异常类 (Custom Exception Classes)：可以根据应用程序的需求，自定义异常类。自定义异常类通常应该继承自 (Inherit From) std::exception 或其派生类，以便与 C++ 异常处理框架更好地集成。自定义异常类可以携带更丰富的错误信息，例如，业务相关的错误代码、上下文数据等。
作用：
⚝ 指示异常发生 (Indicate Exception Occurrence)：throw 表达式用于明确地指示程序遇到了异常情况。当执行到 throw 表达式时，程序会立即停止 (Immediately Stop) 当前代码块的执行，并开始查找 (Search For) 能够处理该异常的 catch 块。
⚝ 传递异常对象 (Pass Exception Object)：throw 表达式会将创建的异常对象传递给异常处理机制。异常对象会被复制 (Copied) (或移动，如果支持移动语义) 到异常处理系统内部，然后与 catch 块声明的异常类型进行匹配。catch 块可以通过异常声明中的变量名访问异常对象的副本，获取异常的详细信息。
用法示例：
1
#include <iostream>
2
#include <stdexcept>
3
#include <string>
4
5
// 自定义异常类 (Custom Exception Class)
6
class MyException : public std::exception {
7
public:
8
MyException(const std::string& message) : message_(message) {}
9
const char* what() const noexcept override { return message_.c_str(); } // 重写 what() 方法 (Override what() method)
10
private:
11
std::string message_;
12
};
13
14
void process_data(int data) {
15
if (data < 0) {
16
throw std::invalid_argument("Data cannot be negative"); // 抛出 std::invalid_argument 异常 (Throw std::invalid_argument exception)
17
}
18
if (data > 100) {
19
throw MyException("Data is out of range ( > 100 )"); // 抛出自定义异常 MyException (Throw custom exception MyException)
20
}
21
// ... 正常数据处理逻辑 (Normal data processing logic) ...
22
std::cout << "Processing data: " << data << std::endl;
23
}
24
25
int main() {
26
try {
27
process_data(50); // 正常调用 (Normal call)
28
process_data(-10); // 抛出 std::invalid_argument 异常 (Throws std::invalid_argument exception)
29
process_data(150); // 抛出 MyException 异常 (Throws MyException exception)
30
}
31
catch (const std::invalid_argument& error) { // 捕获 std::invalid_argument 异常 (Catch std::invalid_argument exception)
32
std::cerr << "Invalid argument: " << error.what() << std::endl;
33
}
34
catch (const MyException& error) { // 捕获 MyException 异常 (Catch MyException exception)
35
std::cerr << "MyException caught: " << error.what() << std::endl;
36
}
37
catch (const std::exception& error) { // 捕获 std::exception 基类异常 (Catch std::exception base class exception)
38
std::cerr << "Standard exception caught: " << error.what() << std::endl;
39
}
40
catch (...) { // 捕获所有其他异常 (Catch all other exceptions)
41
std::cerr << "Unknown exception caught." << std::endl;
42
}
43
44
std::cout << "Program continues after exception handling." << std::endl; // 程序在异常处理后继续执行 (Program continues after exception handling)
45
return 0;
46
}
要点：
⚝ throw 表达式的操作数 (Operand) 可以是任何合法的 C++ 表达式，但通常是异常对象 (Exception Object) 的构造函数调用，例如，throw std::runtime_error("File not found"); 或 throw MyException("Custom error message");。
⚝ throw 表达式的执行会导致程序控制流 (Program Control Flow) 立即跳转到与之匹配的 catch 块。throw 表达式之后的代码不会被执行 (Will Not Be Executed) (除非在 try-catch 块外部)。
⚝ throw 表达式可以在任何可能检测到异常情况的地方使用，例如，在函数内部、在类的成员函数中、在运算符重载函数中，甚至在构造函数中。
⚝ 在析构函数 (Destructor) 中抛出异常通常被认为是不安全的，应该尽量避免在析构函数中抛出异常。如果析构函数中可能发生错误，应该考虑使用其他错误处理机制，例如，设置错误标志、记录日志等。
1.3.4 异常处理流程详解 (Detailed Exception Handling Flow)
当异常发生时，C++ 异常处理机制会按照一定的流程来查找和处理异常。理解异常处理流程对于编写正确的异常处理代码至关重要。
异常处理流程步骤：
① 异常抛出 (Exception is Thrown)：当程序在 try 块内部执行时，如果遇到异常情况，例如，函数调用失败、条件不满足等，程序会使用 throw 表达式抛出一个异常对象。
② 查找 catch 块 (Catch Block Lookup)：异常被抛出后，C++ 运行时系统会沿着调用栈 (Call Stack) 向上查找，寻找与抛出的异常类型匹配 (Matching) 的 catch 块。查找过程从最近的 try 块 (Nearest try block) 开始，向外层 try 块逐层搜索。
③ 栈展开 (Stack Unwinding)：在查找 catch 块的过程中，如果从当前函数到抛出异常的 try 块之间的函数调用栈帧 (Stack Frame) 中，没有任何 catch 块能够处理该异常，则会发生 栈展开 (Stack Unwinding)。栈展开是一个逆序 (Reverse Order) 的过程，从异常抛出点 (Exception Throw Point) 开始，沿着调用栈逐层回退 (Step Back Layer by Layer)，直到找到一个能够处理该异常的 catch 块，或者到达 main 函数的栈帧。在栈展开的过程中，对于每个被展开的栈帧，局部对象 (Local Objects) 会按照构造顺序的逆序 (Reverse Order of Construction) 依次调用析构函数 (Destructors)，以确保资源的正确释放。这个过程也称为 作用域清理 (Scope Cleanup)。
④ catch 块匹配 (Catch Block Matching)：运行时系统在每个 try 块的 catch 子句列表中，按照 catch 块出现的顺序 (Order of Appearance) 依次检查。对于每个 catch 块，运行时系统会比较 catch 块声明的异常类型与抛出的异常类型是否匹配 (Match)。匹配规则如下：
▮▮▮▮ⓐ 完全匹配 (Exact Match)：抛出的异常类型与 catch 块声明的异常类型完全相同。
▮▮▮▮ⓑ 类型转换匹配 (Type Conversion Match)：
▮▮▮▮▮▮▮▮❸ 派生类到基类的转换 (Derived Class to Base Class Conversion)：如果 catch 块声明的异常类型是抛出的异常类型的基类 (Base Class)，则匹配成功。例如，如果抛出的是 std::runtime_error 类型的异常，而 catch 块声明的是 std::exception 类型的异常，则匹配成功，因为 std::runtime_error 继承自 std::exception。
▮▮▮▮▮▮▮▮❹ 非 const 到 const 的转换 (Non-const to const Conversion)：如果 catch 块声明的异常类型是 const 类型的，而抛出的异常类型是非 const 类型的，则匹配成功。例如，如果抛出的是 std::runtime_error 类型的异常，而 catch 块声明的是 const std::runtime_error& 类型的异常，则匹配成功。
▮▮▮▮ⓒ 省略号 ... 匹配 (Ellipsis ... Match)：catch(...) 块可以匹配任何类型 (Any Type) 的异常。
⑤ catch 块执行 (Catch Block Execution)：如果找到一个匹配的 catch 块，程序控制权会转移 (Transfer) 到该 catch 块，执行 catch 块内部的异常处理代码。catch 块执行完毕后，程序会继续执行 (Continue Execution) try-catch 块之后的代码，仿佛异常从未发生过一样。
⑥ 异常未处理 (Uncaught Exception)：如果在整个调用栈中都没有找到能够匹配抛出的异常类型的 catch 块，则该异常被认为是 未捕获异常 (Uncaught Exception)。对于未捕获异常，C++ 运行时系统会调用 std::terminate() 函数，默认情况下，std::terminate() 函数会调用 std::abort() 函数，导致程序异常终止 (Abnormal Termination)。可以通过 std::set_terminate() 函数自定义 std::terminate_handler，来自定义未捕获异常的处理方式。
异常处理流程图：
1
graph LR
2
A[程序执行到 try 块] --> B{try 块内是否抛出异常？};
3
B -- 是 --> C[抛出异常];
4
B -- 否 --> D[顺序执行 try 块代码];
5
D --> E[跳过 catch 块];
6
E --> F[执行 try-catch 块之后的代码];
7
C --> G[查找匹配的 catch 块];
8
G --> H{找到匹配的 catch 块？};
9
H -- 是 --> I[执行匹配的 catch 块];
10
I --> F;
11
H -- 否 --> J[栈展开 (Stack Unwinding)];
12
J --> G;
13
G -- 调用栈顶未找到匹配的 catch 块 --> K[未捕获异常 (Uncaught Exception)];
14
K --> L[调用 std::terminate()];
15
L --> M[程序异常终止 (Abnormal Termination)];
16
F --> N[程序正常结束];
示例代码和流程分析：
1
#include <iostream>
2
#include <stdexcept>
3
4
void func3() {
5
std::cout << "func3: entering" << std::endl;
6
throw std::runtime_error("Exception from func3"); // 抛出异常 (Throw exception)
7
std::cout << "func3: exiting" << std::endl; // 这行代码不会被执行 (This line will not be executed)
8
}
9
10
void func2() {
11
std::cout << "func2: entering" << std::endl;
12
func3(); // 调用 func3, func3 抛出异常 (Call func3, func3 throws exception)
13
std::cout << "func2: exiting" << std::endl; // 这行代码不会被执行 (This line will not be executed)
14
}
15
16
void func1() {
17
std::cout << "func1: entering" << std::endl;
18
try {
19
func2(); // 调用 func2, func2 调用 func3, func3 抛出异常 (Call func2, func2 calls func3, func3 throws exception)
20
}
21
catch (const std::runtime_error& error) { // 捕获 std::runtime_error 类型的异常 (Catch std::runtime_error type exception)
22
std::cerr << "Exception caught in func1: " << error.what() << std::endl; // 处理异常 (Handle exception)
23
}
24
std::cout << "func1: exiting" << std::endl; // 这行代码会被执行 (This line will be executed)
25
}
26
27
int main() {
28
std::cout << "main: entering" << std::endl;
29
func1(); // 调用 func1, func1 内部 try-catch 处理异常 (Call func1, exception is handled inside func1)
30
std::cout << "main: exiting" << std::endl; // 这行代码会被执行 (This line will be executed)
31
return 0;
32
}
程序输出：
1
main: entering
2
func1: entering
3
func2: entering
4
func3: entering
5
Exception caught in func1: Exception from func3
6
func1: exiting
7
main: exiting
流程分析：
main函数调用func1。func1函数调用func2。func2函数调用func3。func3函数抛出一个std::runtime_error类型的异常。- 异常抛出后，开始查找
catch块。首先在func3函数内部查找，未找到。 - 进行栈展开，回退到
func2函数的栈帧，继续查找，未找到。 - 继续栈展开，回退到
func1函数的栈帧，在func1函数的try块后面找到了一个catch(const std::runtime_error& error)块，类型匹配成功。 - 执行
func1函数的catch块中的异常处理代码，输出错误信息 "Exception caught in func1: Exception from func3"。 func1函数的catch块执行完毕，程序继续执行func1函数try-catch块之后的代码，输出 "func1: exiting"。func1函数执行完毕，返回main函数。main函数继续执行func1()调用之后的代码，输出 "main: exiting"。- 程序正常结束。
通过这个例子，可以清晰地看到异常的抛出、栈展开、catch 块的匹配和执行，以及程序控制流的转移过程。理解这些基本概念和流程，是深入学习和应用 C++ 异常处理机制的关键。
2. 深入 catch 子句：异常的捕获与处理 (In-depth catch Clause: Catching and Handling Exceptions)
本章深入探讨 catch 子句的各种用法，包括捕获不同类型的异常、使用省略号 ... 捕获所有异常、以及异常处理函数。catch 子句是 C++ 异常处理机制中至关重要的一部分，它负责接收由 throw 表达式抛出的异常，并执行相应的异常处理代码。理解 catch 子句的不同形式和使用方法，对于编写健壮、可靠的 C++ 程序至关重要。本章将从最基本的特定类型异常捕获开始，逐步深入到捕获所有异常，以及多重 catch 子句的应用，帮助读者全面掌握 catch 子句的使用技巧。
2.1 捕获特定类型的异常 (Catching Specific Exception Types)
catch 子句最常见的用法是捕获特定类型的异常。这意味着您可以根据异常的类型，编写专门的代码来处理不同种类的错误情况。C++ 允许您指定 catch 子句可以捕获的异常类型，只有当抛出的异常类型与 catch 子句声明的类型兼容时，该 catch 子句才会被执行。这种机制使得异常处理更加精细化，可以针对不同的异常情况采取不同的处理策略。
2.1.1 按类型捕获 (Catch by Type)
按类型捕获 (Catch by Type) 是 catch 子句最基本的形式。它通过在 catch 关键字后的括号中声明异常类型来实现。当 try 块中抛出的异常类型与 catch 子句声明的类型完全匹配，或者抛出的异常类型是 catch 子句声明类型的派生类时，该 catch 子句就会被激活并执行。
例如，假设我们有以下代码，其中可能会抛出 int 类型的异常：
1
#include <iostream>
2
#include <stdexcept>
3
4
void divide(int a, int b) {
5
if (b == 0) {
6
throw 1; // 抛出 int 类型的异常
7
}
8
std::cout << "Result: " << a / b << std::endl;
9
}
10
11
int main() {
12
try {
13
divide(10, 0);
14
} catch (int e) { // catch 子句，捕获 int 类型的异常
15
std::cerr << "Caught an integer exception: " << e << std::endl;
16
}
17
std::cout << "Program continues after exception handling." << std::endl;
18
return 0;
19
}
在这个例子中，divide 函数在除数为 0 时抛出了一个 int 类型的异常 1。main 函数的 try 块包裹了 divide 函数的调用，并提供了一个 catch(int e) 子句。当 divide 函数抛出 int 类型的异常时，控制流会立即跳转到匹配的 catch 子句，输出错误信息 "Caught an integer exception: 1"。
除了基本类型，catch 子句也可以捕获自定义类型的异常。例如：
1
#include <iostream>
2
#include <stdexcept>
3
4
class MyException : public std::exception {
5
public:
6
const char* what() const noexcept override {
7
return "This is a custom exception!";
8
}
9
};
10
11
void process_data(int data) {
12
if (data < 0) {
13
throw MyException(); // 抛出自定义异常
14
}
15
std::cout << "Processing data: " << data << std::endl;
16
}
17
18
int main() {
19
try {
20
process_data(-5);
21
} catch (MyException& ex) { // catch 子句，捕获 MyException 类型的异常
22
std::cerr << "Caught a custom exception: " << ex.what() << std::endl;
23
}
24
std::cout << "Program continues after exception handling." << std::endl;
25
return 0;
26
}
在这个例子中，我们定义了一个自定义异常类 MyException，它继承自 std::exception。process_data 函数在输入数据小于 0 时抛出 MyException 类型的异常。main 函数的 catch(MyException& ex) 子句成功捕获了这个自定义异常，并输出了异常信息 "Caught a custom exception: This is a custom exception!"。
2.1.2 按引用捕获 (Catch by Reference)
在 catch 子句中，通常建议按引用捕获 (Catch by Reference) 异常对象，而不是按值捕获 (Catch by Value)。按引用捕获的主要优势在于：
① 避免对象切割 (Object Slicing)：当抛出的异常对象是派生类对象，而 catch 子句按值捕获基类对象时，会发生对象切割。这意味着只有基类部分会被复制到 catch 子句的异常对象中，派生类特有的信息会丢失。按引用捕获可以避免对象切割，确保 catch 子句能够完整地访问异常对象的所有信息，包括派生类特有的成员。
② 提高效率：按值捕获会触发异常对象的拷贝构造函数，而按引用捕获则不会。对于复杂的异常对象，拷贝构造的开销可能比较大。按引用捕获可以避免不必要的对象拷贝，提高异常处理的效率。
③ 允许修改异常对象：虽然在 catch 块中修改异常对象通常不是一个好主意，但在某些特殊情况下，可能需要在 catch 块中修改异常对象的状态。按引用捕获允许在 catch 块中修改原始的异常对象，而按值捕获则只能修改拷贝的对象。
以下代码示例展示了按值捕获和按引用捕获的区别，以及对象切割问题：
1
#include <iostream>
2
#include <stdexcept>
3
4
class BaseException : public std::exception {
5
public:
6
BaseException(const std::string& msg) : message(msg) {}
7
const char* what() const noexcept override {
8
return message.c_str();
9
}
10
protected:
11
std::string message;
12
};
13
14
class DerivedException : public BaseException {
15
public:
16
DerivedException(const std::string& msg, int errorCode) : BaseException(msg), code(errorCode) {}
17
int getErrorCode() const { return code; }
18
private:
19
int code;
20
};
21
22
void throw_exception(int type) {
23
if (type == 1) {
24
throw BaseException("Base exception thrown!");
25
} else if (type == 2) {
26
throw DerivedException("Derived exception thrown!", 101);
27
}
28
}
29
30
void catch_by_value() {
31
try {
32
throw_exception(2); // 抛出 DerivedException
33
} catch (BaseException e) { // 按值捕获 BaseException
34
std::cerr << "Caught by value: " << e.what() << std::endl;
35
// 无法访问 e.getErrorCode()，因为对象被切割
36
}
37
}
38
39
void catch_by_reference() {
40
try {
41
throw_exception(2); // 抛出 DerivedException
42
} catch (BaseException& e) { // 按引用捕获 BaseException
43
std::cerr << "Caught by reference: " << e.what() << std::endl;
44
DerivedException* derivedPtr = dynamic_cast<DerivedException*>(&e);
45
if (derivedPtr) {
46
std::cerr << "Error Code: " << derivedPtr->getErrorCode() << std::endl; // 可以访问派生类成员
47
}
48
}
49
}
50
51
int main() {
52
std::cout << "Catching by value:" << std::endl;
53
catch_by_value();
54
std::cout << "\nCatching by reference:" << std::endl;
55
catch_by_reference();
56
return 0;
57
}
在这个例子中，DerivedException 继承自 BaseException，并添加了一个 errorCode 成员。catch_by_value 函数按值捕获 BaseException，导致对象切割，无法访问 DerivedException 的 getErrorCode() 方法。而 catch_by_reference 函数按引用捕获 BaseException&，避免了对象切割，可以通过 dynamic_cast 将基类引用转换为派生类指针，并访问 DerivedException 的 getErrorCode() 方法。
输出结果如下：
1
Catching by value:
2
Caught by value: Derived exception thrown!
3
4
Catching by reference:
5
Caught by reference: Derived exception thrown!
6
Error Code: 101
可以看到，按引用捕获能够保留派生类异常对象的完整信息。
2.1.3 按常量引用捕获 (Catch by Const Reference)
按常量引用捕获 (Catch by Const Reference) 是按引用捕获的一种变体，它使用 const 关键字修饰引用类型，例如 catch (const BaseException& e)。按常量引用捕获结合了按引用捕获的优点，同时增加了安全性。
使用常量引用捕获异常的优势在于：
① 防止意外修改异常对象：在 catch 块中，异常对象通常只用于读取错误信息，而不是修改其状态。使用常量引用可以明确地表明 catch 块不会修改异常对象，防止在 catch 块中意外地修改异常对象。这有助于提高代码的可读性和可维护性，并减少潜在的错误。
② 兼容性更广：常量引用可以绑定到常量对象和非常量对象。这意味着 catch (const BaseException& e) 可以捕获 throw BaseException("...") 抛出的临时对象，也可以捕获 BaseException ex("..."); throw ex; 抛出的具名对象。
在大多数情况下，按常量引用捕获异常是最佳实践。它既能避免对象切割和提高效率，又能防止意外修改异常对象，并具有更广泛的兼容性。
1
#include <iostream>
2
#include <stdexcept>
3
4
class MyException : public std::exception {
5
public:
6
MyException(std::string msg) : message(std::move(msg)) {}
7
const char* what() const noexcept override {
8
return message.c_str();
9
}
10
private:
11
std::string message;
12
};
13
14
void process_data(int data) {
15
if (data < 0) {
16
throw MyException("Invalid data value: " + std::to_string(data));
17
}
18
std::cout << "Processing data: " << data << std::endl;
19
}
20
21
int main() {
22
try {
23
process_data(-10);
24
} catch (const MyException& ex) { // 按常量引用捕获 MyException
25
std::cerr << "Caught a constant reference exception: " << ex.what() << std::endl;
26
// ex 是常量引用，不能被修改
27
// ex.message = "Modified message"; // 编译错误：expression must be a modifiable lvalue
28
}
29
std::cout << "Program continues after exception handling." << std::endl;
30
return 0;
31
}
在这个例子中，catch (const MyException& ex) 使用常量引用捕获 MyException 类型的异常。在 catch 块中，我们尝试修改 ex.message 成员，导致编译错误，因为 ex 是常量引用，不能被修改。这确保了 catch 块不会意外地修改异常对象的状态。
2.2 捕获所有异常：省略号 ... (Catching All Exceptions: Ellipsis ...)
C++ 提供了 catch(...) 语法，使用省略号 ... 作为 catch 子句的参数，用于捕获所有类型的异常 (Catching All Exceptions)。这种 catch 子句被称为 catch-all 子句。catch(...) 子句会捕获任何类型的异常，无论其类型是什么，即使是基本类型（如 int, char*）或自定义类型，都会被 catch(...) 子句捕获。
2.2.1 catch(...) 的语法和用法 (catch(...) Syntax and Usage)
catch(...) 的语法非常简洁，只需要在 catch 关键字后的括号中放置省略号 ... 即可。catch(...) 子句通常放在多重 catch 子句列表的最后，作为最后的、通用的异常处理器。
1
#include <iostream>
2
#include <stdexcept>
3
4
void might_throw(int type) {
5
if (type == 1) {
6
throw 1;
7
} else if (type == 2) {
8
throw std::runtime_error("Runtime error!");
9
} else if (type == 3) {
10
throw "C-style string exception";
11
}
12
}
13
14
int main() {
15
for (int i = 1; i <= 4; ++i) {
16
try {
17
might_throw(i);
18
} catch (int e) {
19
std::cerr << "Caught int exception: " << e << std::endl;
20
} catch (const std::runtime_error& e) {
21
std::cerr << "Caught runtime_error: " << e.what() << std::endl;
22
} catch (...) { // catch(...) 子句，捕获所有其他类型的异常
23
std::cerr << "Caught unknown exception!" << std::endl;
24
}
25
}
26
return 0;
27
}
在这个例子中，might_throw 函数根据不同的 type 值抛出不同类型的异常：int、std::runtime_error 和 char*。main 函数的 try 块后面有三个 catch 子句：
① catch (int e)：捕获 int 类型的异常。
② catch (const std::runtime_error& e)：捕获 std::runtime_error 类型的异常。
③ catch (...)：捕获所有其他类型的异常。
当 might_throw(1) 抛出 int 异常时，第一个 catch 子句被执行。当 might_throw(2) 抛出 std::runtime_error 异常时，第二个 catch 子句被执行。当 might_throw(3) 抛出 char* 异常时，前两个 catch 子句都不匹配，但 catch(...) 子句会捕获这个 char* 异常。当 might_throw(4) 没有抛出异常时，任何 catch 子句都不会被执行。
输出结果如下：
1
Caught int exception: 1
2
Caught runtime_error: Runtime error!
3
Caught unknown exception!
可以看到，catch(...) 子句成功地捕获了 char* 类型的异常，并输出了 "Caught unknown exception!"。
2.2.2 catch(...) 的适用场景和局限性 (Use Cases and Limitations of catch(...))
catch(...) 子句在某些特定场景下非常有用，但也有其局限性。
适用场景：
① 日志记录 (Logging)：在顶层的异常处理程序中，可以使用 catch(...) 捕获所有未被处理的异常，并记录错误日志。这可以帮助开发者了解程序运行时发生的异常情况，即使这些异常没有被精确地处理。
② 资源清理 (Resource Cleanup)：在某些情况下，即使无法确定异常类型，也需要进行一些通用的资源清理操作，例如释放内存、关闭文件句柄等。catch(...) 可以确保在任何异常发生时，都能执行这些清理操作。
③ 防止程序崩溃 (Preventing Program Termination)：在某些关键的程序组件中，为了防止程序因为未处理的异常而崩溃，可以使用 catch(...) 捕获所有异常，并进行一些默认的错误处理，例如返回一个错误状态，而不是让程序终止。
局限性：
① 信息丢失 (Information Loss)：catch(...) 子句无法获取异常对象的具体类型和值。这意味着在 catch(...) 块中，无法根据异常类型进行精细化的处理。这可能会限制异常处理的灵活性和有效性。
② 隐藏错误 (Hiding Errors)：过度使用 catch(...) 可能会隐藏程序中潜在的错误。如果程序中抛出了一个本应该被特定 catch 子句处理的异常，但被通用的 catch(...) 子句捕获，那么这个错误可能会被忽略，导致程序在错误的状态下继续运行，或者在稍后的某个时刻引发更难以追踪的错误。
③ 不利于调试 (Debugging Difficulties)：当异常被 catch(...) 捕获时，由于无法获取异常类型信息，可能会给调试带来困难。开发者可能需要花费更多的时间来定位和解决问题。
最佳实践：
⚝ 谨慎使用 catch(...)：除非有充分的理由，否则应尽量避免使用 catch(...)。优先使用特定类型的 catch 子句，以便进行更精确的异常处理。
⚝ 仅在顶层使用：如果确实需要使用 catch(...)，应尽量将其限制在程序的顶层，例如 main 函数的 try-catch 块中，用于捕获最外层的未处理异常。
⚝ 记录错误信息：在 catch(...) 块中，务必记录详细的错误日志，包括异常发生的时间、位置、以及可能的上下文信息。这有助于后续的错误分析和调试。
⚝ 考虑重新抛出异常：在 catch(...) 块中，可以考虑重新抛出异常，以便将异常传递给更外层的异常处理程序，或者让程序终止并生成 core dump 文件，以便进行更深入的调试。
2.2.3 重新抛出异常：throw; (Re-throwing Exceptions: throw;)
在 catch(...) 块中，有时需要将捕获的异常重新抛出 (Re-throwing Exceptions)，以便将异常传递给更外层的异常处理程序，或者触发默认的未捕获异常处理机制。C++ 提供了 throw; 语句，用于在 catch 块中重新抛出当前正在处理的异常。
throw; 语句与 throw exception_object; 不同。throw exception_object; 会抛出一个新的异常对象，而 throw; 则会重新抛出原始的异常对象。这意味着重新抛出的异常的类型和值都与原始异常完全相同。
1
#include <iostream>
2
#include <stdexcept>
3
4
void inner_function() {
5
throw std::runtime_error("Exception from inner function");
6
}
7
8
void middle_function() {
9
try {
10
inner_function();
11
} catch (...) {
12
std::cerr << "Caught in middle function, re-throwing." << std::endl;
13
throw; // 重新抛出异常
14
}
15
}
16
17
int main() {
18
try {
19
middle_function();
20
} catch (const std::exception& e) {
21
std::cerr << "Caught in main function: " << e.what() << std::endl;
22
}
23
return 0;
24
}
在这个例子中，inner_function 抛出一个 std::runtime_error 异常。middle_function 的 try-catch 块使用 catch(...) 捕获所有异常，并输出 "Caught in middle function, re-throwing."，然后使用 throw; 重新抛出异常。main 函数的 try-catch 块捕获 std::exception 类型的异常，并输出异常信息 "Caught in main function: Exception from inner function"。
输出结果如下：
1
Caught in middle function, re-throwing.
2
Caught in main function: Exception from inner function
可以看到，异常首先在 middle_function 中被 catch(...) 捕获，然后通过 throw; 重新抛出，最终在 main 函数中被 catch (const std::exception& e) 捕获。
throw; 的应用场景：
① 部分处理异常：在某些情况下，catch 块可能只需要进行部分异常处理，例如记录日志、清理资源，然后将异常传递给更外层的异常处理程序进行进一步处理。这时可以使用 throw; 重新抛出异常。
② 异常转换 (Exception Translation)：有时需要将一种异常类型转换为另一种更适合上层处理的异常类型。在异常转换的过程中，可能需要先捕获原始异常，进行一些处理，然后再抛出新的异常。throw; 可以用于在异常转换的过程中，保留原始异常的信息，并将其传递给新的异常处理程序。
③ 在 catch(...) 中重新抛出：由于 catch(...) 无法获取异常类型信息，如果需要在 catch(...) 中进行一些通用处理后，仍然希望将异常传递给更外层的异常处理程序进行类型相关的处理，可以使用 throw; 重新抛出异常。
注意：如果在 catch 块中没有捕获到任何异常，直接使用 throw; 会导致程序终止，调用 std::terminate() 函数。throw; 只能在 catch 块中使用，并且必须在已经捕获到异常的情况下才能正常工作。
2.3 多重 catch 子句与异常类型匹配 (Multiple catch Clauses and Exception Type Matching)
在一个 try 块后面，可以跟随多个 catch 子句 (Multiple catch Clauses)，每个 catch 子句可以捕获不同类型的异常。当 try 块中抛出异常时，C++ 运行时系统会按照 catch 子句在代码中出现的顺序，依次检查每个 catch 子句的异常类型是否与抛出的异常类型匹配。第一个匹配的 catch 子句会被执行，后续的 catch 子句将被忽略。如果没有找到匹配的 catch 子句，异常将继续向外层传播，直到被外层的 try-catch 块捕获，或者最终导致程序终止。
2.3.1 顺序匹配原则 (Sequential Matching Principle)
顺序匹配原则 (Sequential Matching Principle) 是指 C++ 运行时系统在查找匹配的 catch 子句时，会按照 catch 子句在代码中出现的顺序进行查找。一旦找到第一个匹配的 catch 子句，就会立即执行该 catch 子句，并停止查找。这意味着 catch 子句的顺序非常重要，错误的顺序可能会导致某些 catch 子句永远不会被执行，或者捕获到不期望类型的异常。
1
#include <iostream>
2
#include <stdexcept>
3
4
void throw_exceptions(int type) {
5
if (type == 1) {
6
throw std::runtime_error("Runtime error!");
7
} else if (type == 2) {
8
throw std::logic_error("Logic error!");
9
} else if (type == 3) {
10
throw std::exception();
11
}
12
}
13
14
int main() {
15
for (int i = 1; i <= 3; ++i) {
16
std::cout << "\nThrowing exception type: " << i << std::endl;
17
try {
18
throw_exceptions(i);
19
} catch (const std::logic_error& e) {
20
std::cerr << "Caught logic_error: " << e.what() << std::endl;
21
} catch (const std::runtime_error& e) {
22
std::cerr << "Caught runtime_error: " << e.what() << std::endl;
23
} catch (const std::exception& e) {
24
std::cerr << "Caught exception: " << e.what() << std::endl;
25
} catch (...) {
26
std::cerr << "Caught unknown exception!" << std::endl;
27
}
28
}
29
return 0;
30
}
在这个例子中，throw_exceptions 函数根据 type 值抛出不同类型的标准异常：std::runtime_error, std::logic_error, std::exception。main 函数的 try 块后面有四个 catch 子句，按照从派生类到基类的顺序排列：std::logic_error, std::runtime_error, std::exception, ...。
当 throw_exceptions(1) 抛出 std::runtime_error 异常时，运行时系统会首先检查 catch (const std::logic_error& e)，类型不匹配。然后检查 catch (const std::runtime_error& e)，类型匹配，因此执行该 catch 子句，输出 "Caught runtime_error: Runtime error!"。后续的 catch 子句被忽略。
当 throw_exceptions(2) 抛出 std::logic_error 异常时，运行时系统会首先检查 catch (const std::logic_error& e)，类型匹配，因此执行该 catch 子句，输出 "Caught logic_error: Logic error!"。后续的 catch 子句被忽略。
当 throw_exceptions(3) 抛出 std::exception 异常时，运行时系统会首先检查 catch (const std::logic_error& e)，类型不匹配。然后检查 catch (const std::runtime_error& e)，类型也不匹配。接着检查 catch (const std::exception& e)，类型匹配，因为 std::exception 是 std::exception 自身的基类。因此执行该 catch 子句，输出 "Caught exception: std::exception"。最后的 catch(...) 子句被忽略。
错误的 catch 子句顺序：
如果将 catch (const std::exception& e) 子句放在最前面，例如：
1
try {
2
throw_exceptions(i);
3
} catch (const std::exception& e) { // 基类 catch 子句放在最前面
4
std::cerr << "Caught exception: " << e.what() << std::endl;
5
} catch (const std::logic_error& e) { // 派生类 catch 子句
6
std::cerr << "Caught logic_error: " << e.what() << std::endl;
7
} catch (const std::runtime_error& e) { // 派生类 catch 子句
8
std::cerr << "Caught runtime_error: " << e.what() << std::endl;
9
} catch (...) {
10
std::cerr << "Caught unknown exception!" << std::endl;
11
}
在这种情况下，无论 throw_exceptions 函数抛出什么类型的异常，都会被第一个 catch (const std::exception& e) 子句捕获，因为 std::logic_error 和 std::runtime_error 都是 std::exception 的派生类。后续的 catch (const std::logic_error& e) 和 catch (const std::runtime_error& e) 子句将永远不会被执行。
输出结果将变为：
1
Throwing exception type: 1
2
Caught exception: Runtime error!
3
4
Throwing exception type: 2
5
Caught exception: Logic error!
6
7
Throwing exception type: 3
8
Caught exception: std::exception
可以看到，所有的异常都被 catch (const std::exception& e) 子句捕获了。
2.3.2 异常类型转换与继承关系 (Exception Type Conversion and Inheritance)
在异常处理中，异常类型转换 (Exception Type Conversion) 和继承关系 (Inheritance) 起着重要的作用。当抛出一个派生类异常对象时，它可以被捕获基类类型的 catch 子句捕获。这基于 C++ 的is-a关系：派生类对象也是基类对象的一种。
类型匹配规则：
① 完全匹配：如果抛出的异常类型与 catch 子句声明的类型完全相同，则匹配成功。
② 派生类到基类的转换：如果抛出的异常类型是 catch 子句声明类型的派生类，则匹配成功。这是因为可以进行隐式的派生类到基类的类型转换。
③ 指针或引用转换：如果 catch 子句捕获的是指针或引用类型，并且抛出的异常类型可以转换为 catch 子句声明的指针或引用类型（例如，派生类指针或引用可以转换为基类指针或引用），则匹配成功。
④ catch(...) 匹配任何类型：catch(...) 子句可以捕获任何类型的异常。
不匹配的情况：
① 基类到派生类的转换：不能将基类异常对象隐式转换为派生类类型。因此，如果抛出的是基类异常，catch 派生类类型的子句不会匹配。
② 无关类型：如果抛出的异常类型与 catch 子句声明的类型既不是完全相同，也没有继承关系，则不匹配。
例如，考虑以下继承结构：
1
std::exception
2
├── std::runtime_error
3
│ └── std::overflow_error
4
└── std::logic_error
5
└── std::invalid_argument
⚝ catch (const std::exception& e) 可以捕获 std::exception, std::runtime_error, std::logic_error, std::overflow_error, std::invalid_argument 等类型的异常。
⚝ catch (const std::runtime_error& e) 可以捕获 std::runtime_error, std::overflow_error 等类型的异常，但不能捕获 std::logic_error 或 std::exception 类型的异常。
⚝ catch (const std::overflow_error& e) 只能捕获 std::overflow_error 类型的异常。
1
#include <iostream>
2
#include <stdexcept>
3
4
void throw_derived_exception() {
5
throw std::overflow_error("Overflow error occurred!");
6
}
7
8
int main() {
9
try {
10
throw_derived_exception();
11
} catch (const std::exception& e) { // 捕获基类异常
12
std::cerr << "Caught std::exception: " << e.what() << std::endl;
13
} catch (const std::overflow_error& e) { // 捕获派生类异常 (永远不会被执行，因为基类 catch 子句已经捕获了)
14
std::cerr << "Caught std::overflow_error: " << e.what() << std::endl;
15
}
16
return 0;
17
}
在这个例子中，throw_derived_exception 函数抛出 std::overflow_error 异常，它是 std::runtime_error 的派生类，而 std::runtime_error 又是 std::exception 的派生类。main 函数的 try 块后面有两个 catch 子句，第一个 catch (const std::exception& e) 捕获基类 std::exception，第二个 catch (const std::overflow_error& e) 捕获派生类 std::overflow_error。
由于顺序匹配原则，第一个 catch (const std::exception& e) 子句会先被检查，并且由于 std::overflow_error 是 std::exception 的派生类，所以类型匹配成功，执行第一个 catch 子句。第二个 catch (const std::overflow_error& e) 子句永远不会被执行，因为它已经被第一个更通用的 catch 子句覆盖了。
输出结果如下：
1
Caught std::exception: Overflow error occurred!
2.3.3 最佳实践：组织多重 catch 子句 (Best Practices: Organizing Multiple catch Clauses)
为了有效地使用多重 catch 子句，并避免顺序匹配原则带来的潜在问题，以下是一些最佳实践建议：
① 按照异常类型的特异性排序：将更具体的异常类型的 catch 子句放在前面，将更通用的异常类型的 catch 子句放在后面。例如，先 catch 派生类异常，再 catch 基类异常，最后 catch(...)。这样可以确保针对特定异常类型的处理逻辑能够被优先执行。
② 避免使用过于宽泛的 catch 子句：除非必要，尽量避免在多重 catch 子句列表的前面使用过于宽泛的 catch 子句，例如 catch (const std::exception& e) 或 catch(...)。如果将这些宽泛的 catch 子句放在前面，可能会导致更具体的 catch 子句永远不会被执行。
③ 使用注释说明 catch 子句的目的：在多重 catch 子句的代码中，使用清晰的注释说明每个 catch 子句的目的，以及它要处理的异常类型。这有助于提高代码的可读性和可维护性。
④ 考虑异常处理的层次结构：根据程序的模块和功能划分，设计合理的异常处理层次结构。在内层模块中，可以捕获和处理一些局部性的、特定类型的异常。如果内层模块无法完全处理异常，可以将异常重新抛出，传递给外层模块进行更通用的处理。在顶层模块，可以使用 catch(...) 捕获所有未处理的异常，并进行日志记录和错误报告。
⑤ 避免空的 catch 块：除非有明确的理由，否则应尽量避免使用空的 catch 块，即 catch (SomeException) {}。空的 catch 块会吞噬异常，导致错误被忽略，不利于程序的调试和维护。如果 catch 块中不需要执行任何特定的处理逻辑，至少应该记录错误日志或重新抛出异常。
遵循这些最佳实践，可以编写出更加健壮、可维护的异常处理代码，提高程序的可靠性和稳定性。
3. 异常规范与 noexcept (Exception Specifications and noexcept)
3.1 动态异常规范 (Dynamic Exception Specifications) [已废弃] (Deprecated Dynamic Exception Specifications)
3.1.1 动态异常规范的语法和示例 (Syntax and Examples of Dynamic Exception Specifications)
动态异常规范 (dynamic exception specification) 是 C++11 之前版本中用于声明函数可能抛出的异常类型的特性。它允许开发者在函数声明时指定该函数可能抛出的异常类型列表。如果函数抛出了规范中未列出的异常，std::unexpected() 函数会被调用，而 std::unexpected() 默认行为是调用 std::terminate() 终止程序。
动态异常规范的语法是在函数声明的参数列表后，紧跟 throw(异常类型列表)。异常类型列表是由逗号分隔的类型名称组成。例如：
1
void func1() throw(int); // func1() 可能抛出 int 类型的异常
2
void func2() throw(int, std::bad_alloc); // func2() 可能抛出 int 或 std::bad_alloc 类型的异常
3
void func3() throw(); // func3() 声明不抛出任何异常 (C++98/C++03)
4
void func4(); // func4() 没有异常规范，可能抛出任何异常 (C++98/C++03)
示例 1：动态异常规范的基本用法
1
#include <iostream>
2
#include <stdexcept>
3
4
void might_throw_int() throw(int) {
5
if (rand() % 2 == 0) {
6
throw 100; // 抛出 int 类型的异常，符合异常规范
7
}
8
std::cout << "might_throw_int() 没有抛出异常" << std::endl;
9
}
10
11
void might_throw_bad_alloc() throw(std::bad_alloc) {
12
if (rand() % 2 == 0) {
13
throw std::bad_alloc(); // 抛出 std::bad_alloc 类型的异常，符合异常规范
14
}
15
std::cout << "might_throw_bad_alloc() 没有抛出异常" << std::endl;
16
}
17
18
void no_throw() throw() { // 声明不抛出任何异常
19
std::cout << "no_throw() 保证不抛出异常" << std::endl;
20
}
21
22
void might_throw_unexpected() throw(int) {
23
if (rand() % 2 == 0) {
24
throw "unexpected exception"; // 抛出 char* 类型的异常，不符合异常规范
25
}
26
std::cout << "might_throw_unexpected() 没有抛出异常" << std::endl;
27
}
28
29
int main() {
30
try {
31
might_throw_int();
32
} catch (int i) {
33
std::cout << "捕获到 int 异常: " << i << std::endl;
34
}
35
36
try {
37
might_throw_bad_alloc();
38
} catch (const std::bad_alloc& ba) {
39
std::cout << "捕获到 std::bad_alloc 异常: " << ba.what() << std::endl;
40
}
41
42
no_throw();
43
44
try {
45
might_throw_unexpected(); // 可能会调用 std::unexpected()，进而 std::terminate()
46
} catch (int i) { // 这个 catch 块不会被执行，因为异常类型不匹配，且 std::unexpected() 通常会终止程序
47
std::cout << "捕获到 int 异常: " << i << std::endl;
48
} catch (...) {
49
std::cout << "捕获到未知异常" << std::endl; // 如果 std::unexpected() 没有直接终止程序，可能会走到这里，但行为是未定义的，不应依赖
50
}
51
52
return 0;
53
}
在这个例子中，might_throw_int() 声明可能抛出 int 异常，might_throw_bad_alloc() 声明可能抛出 std::bad_alloc 异常，no_throw() 声明不抛出任何异常。 might_throw_unexpected() 声明可能抛出 int 异常，但实际上在某些情况下抛出了 char* 类型的异常，这违反了动态异常规范。在 C++11 之前的版本中，这会导致 std::unexpected() 被调用。
空异常规范 throw()
特别地，throw() (或者在 C++11 之前等价的 throw(...)) 被称为空异常规范 (empty exception specification)，它明确声明函数不应该抛出任何异常。这与没有异常规范的函数 (在 C++11 之前) 不同，后者表示函数可能抛出任何类型的异常。
3.1.2 动态异常规范的问题与废弃 (Problems and Deprecation of Dynamic Exception Specifications)
尽管动态异常规范在早期 C++ 版本中被引入，但它存在诸多问题，最终导致在 C++11 标准中被废弃 (deprecated)，并在 C++17 标准中被移除 (removed)。 主要问题包括：
① 运行时检查开销 (Runtime Overhead)：
为了强制执行动态异常规范，编译器需要在运行时生成额外的代码来检查函数抛出的异常是否符合规范。这种运行时检查会带来性能开销，即使在没有异常抛出的正常情况下也会存在。
② 与模板和泛型编程的兼容性问题 (Compatibility Issues with Templates and Generic Programming)：
动态异常规范与模板 (templates) 和泛型编程 (generic programming) 结合使用时会变得非常复杂和难以维护。模板函数的异常规范很难确定，因为它取决于模板参数的类型。为模板函数提供精确的动态异常规范几乎是不可能的，通常只能使用非常宽泛的规范，降低了动态异常规范的实用价值。
③ 违反了异常处理的设计原则 (Violates Principles of Exception Handling)：
异常处理的主要目的是处理运行时 (runtime) 错误，而动态异常规范试图在编译时 (compile-time) 强制约束函数可能抛出的异常类型。这种编译时的约束与异常处理的动态性质相悖。实际上，很难在编写函数时完全预测所有可能抛出的异常类型，尤其是在复杂的程序中。
④ 维护困难和错误 prone (Maintenance Difficulty and Error-Prone)：
随着代码的演进和修改，动态异常规范很容易变得过时或不准确。维护和更新动态异常规范会增加开发和维护成本，并且容易引入错误。如果动态异常规范不正确，可能会导致程序在运行时意外终止，或者隐藏潜在的错误。
⑤ 与现代 C++ 的发展方向不符 (Inconsistent with Modern C++ Direction)：
现代 C++ 更加强调零开销抽象 (zero-overhead abstraction) 和性能 (performance)。动态异常规范的运行时检查开销与这一目标不符。同时，C++11 引入了 noexcept 说明符，提供了一种更简洁、更有效的方式来声明函数是否可能抛出异常，从而取代了动态异常规范。
废弃和移除
由于上述问题，C++ 标准委员会最终决定废弃并移除动态异常规范。
⚝ C++11 标准：动态异常规范被废弃 (deprecated)。这意味着编译器可能会发出警告，建议开发者不要再使用动态异常规范。但是，为了保持向后兼容性，C++11 标准仍然保留了动态异常规范的语法和语义，只是不再鼓励使用。throw() 在 C++11 中被 noexcept(true) 取代，但 throw() 仍然被保留，并被解释为空的动态异常规范。
⚝ C++17 标准：动态异常规范被移除 (removed)。这意味着 C++17 标准不再支持动态异常规范的语法。尝试在 C++17 代码中使用动态异常规范将导致编译错误。throw() 在 C++17 中仍然被保留，但其含义变更为 noexcept(true)。
总结
动态异常规范是一个失败的语言特性，它试图在编译时强制约束运行时错误，但最终因为各种问题而被废弃和移除。在现代 C++ 中，应该使用 noexcept 说明符来声明函数是否可能抛出异常，而不是使用动态异常规范。 动态异常规范的历史教训告诫我们，在设计语言特性时，需要充分考虑其运行时开销、与现有语言特性的兼容性、以及是否符合语言的设计原则。
3.2 noexcept 说明符 (The noexcept Specifier)
noexcept 说明符 (noexcept specifier) 是 C++11 引入的一个异常说明符 (exception specifier)，用于声明函数是否会抛出异常。与已废弃的动态异常规范不同，noexcept 提供了更简洁、更有效的方式来表达函数的异常行为，并且在现代 C++ 中扮演着重要的角色，尤其是在性能优化 (performance optimization) 和异常安全编程 (exception-safe programming) 方面。
3.2.1 noexcept 的语法和用法 (noexcept Syntax and Usage)
noexcept 说明符有两种形式：
① 无条件 noexcept (Unconditional noexcept):
在函数声明或定义时，在参数列表后直接添加 noexcept 关键字，表示该函数保证不抛出任何异常。
1
void func() noexcept; // 声明：func() 保证不抛出异常
2
void func() noexcept { // 定义：func() 的实现
3
// ... 函数体 ...
4
}
无条件 noexcept 等价于 noexcept(true)。
② 有条件 noexcept (Conditional noexcept):
在函数声明或定义时，在参数列表后添加 noexcept(表达式)，其中 表达式 是一个常量表达式 (constant expression)，其值可以转换为 bool 类型。如果表达式的值为 true，则表示函数保证不抛出异常；如果表达式的值为 false，则表示函数可能抛出异常。
1
void func() noexcept(true); // 声明：func() 保证不抛出异常 (等价于 void func() noexcept;)
2
void func() noexcept(false); // 声明：func() 可能抛出异常
3
void func() noexcept(condition); // 声明：func() 的 noexcept 属性取决于 condition 的值，condition 必须是常量表达式
noexcept 的作用
noexcept 的主要作用是向编译器 (compiler) 和程序员 (programmer) 传达函数是否会抛出异常的信息。
⚝ 对编译器的意义： noexcept 允许编译器进行更积极的优化 (more aggressive optimizations)。当编译器知道一个函数不会抛出异常时，它可以省略一些与异常处理相关的运行时开销，例如栈展开 (stack unwinding) 的准备工作。这可以提高程序的性能，尤其是在移动语义 (move semantics) 和泛型编程 (generic programming) 中。
⚝ 对程序员的意义： noexcept 作为函数接口的一部分，清晰地表明了函数的异常行为。这有助于提高代码的可读性和可维护性，并且可以帮助程序员编写更异常安全 (exception-safe) 的代码。例如，标准库 (standard library) 中的很多函数，特别是移动操作 (move operations) 和析构函数 (destructors)，都被声明为 noexcept，这是异常安全编程的重要保证。
noexcept 运算符 (noexcept operator)
C++11 还引入了 noexcept 运算符 (noexcept operator)，用于在编译时 (compile-time) 检查一个表达式是否可能抛出异常。 noexcept 运算符是一个一元运算符 (unary operator)，接受一个表达式作为操作数，返回一个 bool 类型的编译时常量 (compile-time constant)。
1
noexcept(表达式)
⚝ 如果 表达式 被声明为 noexcept 函数调用，或者是一个不会抛出异常的字面量、变量等，则 noexcept(表达式) 的值为 true。
⚝ 否则，noexcept(表达式) 的值为 false。
示例 2：noexcept 的语法和用法
1
#include <iostream>
2
#include <vector>
3
4
void no_throw_func() noexcept {
5
std::cout << "no_throw_func() called" << std::endl;
6
}
7
8
void may_throw_func() {
9
std::cout << "may_throw_func() called" << std::endl;
10
throw std::runtime_error("Exception from may_throw_func()");
11
}
12
13
template <typename T>
14
void conditional_noexcept_func(T value) noexcept(std::is_nothrow_move_constructible<T>::value) {
15
T temp = std::move(value); // 移动构造，noexcept 属性取决于 T 的移动构造函数
16
std::cout << "conditional_noexcept_func() called" << std::endl;
17
}
18
19
int main() {
20
std::cout << "noexcept(no_throw_func()): " << noexcept(no_throw_func()) << std::endl; // 输出 true
21
std::cout << "noexcept(may_throw_func()): " << noexcept(may_throw_func()) << std::endl; // 输出 false
22
std::cout << "noexcept(1 + 2): " << noexcept(1 + 2) << std::endl; // 输出 true，基本类型运算通常 noexcept
23
24
std::vector<int> vec1 = {1, 2, 3};
25
std::cout << "noexcept(conditional_noexcept_func(vec1)): "
26
<< noexcept(conditional_noexcept_func(vec1)) << std::endl; // 输出 true，std::vector<int> 的移动构造函数通常 noexcept
27
28
try {
29
may_throw_func();
30
} catch (const std::exception& e) {
31
std::cerr << "Caught exception: " << e.what() << std::endl;
32
}
33
34
conditional_noexcept_func(5); // int 是 nothrow_move_constructible，所以 conditional_noexcept_func<int> 是 noexcept 的
35
36
return 0;
37
}
在这个例子中，no_throw_func() 被声明为 noexcept，may_throw_func() 没有 noexcept 说明符 (默认为 noexcept(false))， conditional_noexcept_func() 的 noexcept 属性取决于模板参数 T 的移动构造函数是否是 noexcept 的。noexcept 运算符用于在编译时检查这些函数的 noexcept 属性。
3.2.2 noexcept 的两种形式：无条件与有条件 (Unconditional and Conditional noexcept)
① 无条件 noexcept (Unconditional noexcept)
无条件 noexcept，即直接使用 noexcept 关键字，是最简单也是最常用的形式。它明确声明函数绝对不会抛出异常。如果一个被声明为 noexcept 的函数在运行时真的抛出了异常，会发生什么呢？
⚝ 违反 noexcept 承诺： 当一个被声明为 noexcept 的函数抛出异常时，程序会立即调用 std::terminate() 函数，导致程序异常终止 (abnormal termination)。 这与动态异常规范的行为不同，后者在违反规范时会尝试调用 std::unexpected() (虽然 std::unexpected() 在实践中也很少被使用，并且通常也最终调用 std::terminate())。
⚝ 强制性保证： noexcept 是一种强制性 (mandatory) 的保证。编译器会假设 noexcept 函数不会抛出异常，并基于此进行优化。如果违反了 noexcept 保证，程序会直接终止，而不会像动态异常规范那样尝试捕获或处理违反规范的异常。
适用场景：
⚝ 析构函数 (Destructors)： 析构函数默认应该是 noexcept 的，并且强烈建议不要在析构函数中抛出异常。如果在栈展开 (stack unwinding) 过程中，一个析构函数抛出了异常，而此时已经有异常处于活动状态，程序会立即调用 std::terminate()。
⚝ 移动操作 (Move Operations)： 移动构造函数 (move constructors) 和移动赋值运算符 (move assignment operators) 应该尽可能地声明为 noexcept。标准库的容器 (containers) 和算法 (algorithms) 在很多情况下会依赖于 noexcept 移动操作来实现性能优化和强异常安全保证。
⚝ 交换函数 (Swap Functions)： 用于交换两个对象状态的 swap 函数通常也应该声明为 noexcept。
⚝ 不应该抛出异常的底层函数： 一些底层工具函数或辅助函数，设计上就不应该抛出异常，可以声明为 noexcept 以提高性能和代码清晰度。
② 有条件 noexcept (Conditional noexcept)
有条件 noexcept，即 noexcept(表达式)，允许根据一个编译时常量表达式来决定函数的 noexcept 属性。这在泛型编程 (generic programming) 和模板编程 (template programming) 中非常有用，因为函数的异常行为可能取决于模板参数的类型。
⚝ 条件表达式： noexcept(表达式) 中的 表达式 必须是一个常量表达式 (constant expression)，其值可以转换为 bool 类型。这个表达式通常会涉及到 noexcept 运算符或其他编译时可确定的属性。
⚝ 动态 noexcept 属性： 函数的 noexcept 属性在编译时根据条件表达式的值来确定。如果表达式的值为 true，则函数被视为 noexcept 函数；如果为 false，则被视为可能抛出异常的函数。
适用场景：
⚝ 模板函数和泛型代码： 当函数的异常行为取决于模板参数的特性时，可以使用有条件 noexcept。例如，一个模板函数的移动操作是否 noexcept，取决于模板参数类型的移动操作是否 noexcept。
⚝ 根据类型特性决定 noexcept 属性： 可以使用类型 traits (type traits) 来检查类型的特性，例如 std::is_nothrow_move_constructible<T>::value (检查类型 T 是否具有 noexcept 移动构造函数)，并根据这些特性来决定函数的 noexcept 属性。
示例 3：有条件 noexcept 的应用
1
#include <iostream>
2
#include <type_traits>
3
4
template <typename T>
5
void generic_func(T a, T b) noexcept(std::is_nothrow_move_constructible<T>::value) {
6
T temp = std::move(a); // 移动操作，noexcept 属性取决于 T 的移动构造函数
7
// ... 其他操作 ...
8
std::cout << "generic_func() called, noexcept = " << noexcept(generic_func<T>(a,b)) << std::endl;
9
}
10
11
struct MyType {
12
MyType() = default;
13
MyType(MyType&&) noexcept {} // noexcept 移动构造函数
14
};
15
16
struct AnotherType {
17
AnotherType() = default;
18
AnotherType(AnotherType&&) {} // non-noexcept 移动构造函数
19
};
20
21
int main() {
22
int x = 10, y = 20;
23
generic_func(x, y); // int 的移动构造函数是 noexcept 的，所以 generic_func<int> 是 noexcept 的
24
25
MyType obj1, obj2;
26
generic_func(obj1, obj2); // MyType 的移动构造函数是 noexcept 的，所以 generic_func<MyType> 是 noexcept 的
27
28
AnotherType obj3, obj4;
29
generic_func(obj3, obj4); // AnotherType 的移动构造函数不是 noexcept 的，所以 generic_func<AnotherType> 不是 noexcept 的
30
31
return 0;
32
}
在这个例子中，generic_func() 是一个模板函数，它的 noexcept 属性取决于模板参数 T 的移动构造函数是否是 noexcept 的。使用 std::is_nothrow_move_constructible<T>::value 作为条件表达式，可以根据不同的类型 T 自动推导出 generic_func() 的 noexcept 属性。
3.2.3 noexcept 与性能优化 (Performance Optimization with noexcept)
noexcept 说明符在性能优化方面起着重要的作用。当编译器知道一个函数是 noexcept 的，它可以进行多种优化，从而提高程序的执行效率。主要的性能优化机会包括：
① 减少栈展开开销 (Reduced Stack Unwinding Overhead)：
⚝ 栈展开 (stack unwinding) 是异常处理机制中一个重要的步骤。当异常抛出时，程序需要沿着调用栈逐层回退，析构局部对象，直到找到合适的 catch 块。栈展开的过程是有性能开销的。
⚝ noexcept 函数优化： 对于 noexcept 函数，编译器可以假设在函数执行过程中不会发生异常，因此可以省略一些栈展开的准备工作。例如，编译器可能不需要为 noexcept 函数的局部对象生成栈展开所需的析构代码，或者可以采用更轻量级的栈帧 (stack frame) 结构。
② 优化移动语义 (Optimized Move Semantics)：
⚝ 移动语义 (move semantics) 是 C++11 引入的重要特性，旨在提高对象移动操作的效率，尤其是在处理大型对象时。移动操作通常用于资源转移，而不是深拷贝 (deep copy)。
⚝ noexcept 移动操作的重要性： 标准库的很多容器和算法，例如 std::vector, std::sort 等，在进行元素移动时，会优先选择 noexcept 的移动操作。如果一个类型的移动构造函数或移动赋值运算符是 noexcept 的，标准库可以放心地使用移动操作，而无需担心异常安全问题。
⚝ 例如 std::vector::resize()： 当 std::vector 需要重新分配内存时 (例如 resize(), push_back() 等操作)，如果元素类型的移动构造函数是 noexcept 的，std::vector 可以使用移动构造 (move construction) 来转移元素，而不需要使用拷贝构造 (copy construction)，从而避免不必要的拷贝开销。如果移动构造函数不是 noexcept 的，std::vector 为了保证强异常安全 (strong exception safety)，可能会退而求其次使用拷贝构造，或者采取更复杂的异常处理策略。
③ 内联 (Inlining)：
⚝ 内联 (inlining) 是编译器优化中常用的一种技术，它可以将函数调用替换为函数体本身，从而消除函数调用的开销，并为进一步的优化创造条件。
⚝ noexcept 函数更有利于内联： 编译器在决定是否内联一个函数时，会考虑多种因素，包括函数的大小、复杂度、以及是否会抛出异常。noexcept 函数由于不会抛出异常，通常更符合内联的条件，更容易被编译器内联，从而提高性能。
④ 代码生成优化 (Code Generation Optimization)：
⚝ 更简洁的代码生成： 对于 noexcept 函数，编译器可以生成更简洁、更高效的机器代码。例如，可以减少函数入口和出口处的异常处理相关的代码，简化控制流 (control flow)，并利用更多的寄存器 (registers) 进行优化。
⚝ 指令级并行 (Instruction-Level Parallelism, ILP) 提升： 由于 noexcept 函数的控制流更加简单可预测，编译器更容易进行指令调度 (instruction scheduling) 和其他指令级并行优化，从而充分利用现代处理器的多发射 (multi-issue) 和超标量 (superscalar) 能力。
示例 4：noexcept 对移动语义性能的影响
1
#include <iostream>
2
#include <vector>
3
#include <algorithm>
4
#include <chrono>
5
6
struct MyNonNoexceptType {
7
int data[1000];
8
MyNonNoexceptType() { /* ... 初始化 ... */ }
9
MyNonNoexceptType(const MyNonNoexceptType&) { /* ... 拷贝构造 ... */ }
10
MyNonNoexceptType(MyNonNoexceptType&&) { /* ... 移动构造 (non-noexcept) ... */ }
11
MyNonNoexceptType& operator=(const MyNonNoexceptType&) { /* ... 拷贝赋值 ... */ return *this; }
12
MyNonNoexceptType& operator=(MyNonNoexceptType&&) { /* ... 移动赋值 (non-noexcept) ... */ return *this; }
13
};
14
15
struct MyNoexceptType {
16
int data[1000];
17
MyNoexceptType() { /* ... 初始化 ... */ }
18
MyNoexceptType(const MyNoexceptType&) { /* ... 拷贝构造 ... */ }
19
MyNoexceptType(MyNoexceptType&&) noexcept { /* ... 移动构造 (noexcept) ... */ }
20
MyNoexceptType& operator=(const MyNoexceptType&) { /* ... 拷贝赋值 ... */ return *this; }
21
MyNoexceptType& operator=(MyNoexceptType&&) noexcept { /* ... 移动赋值 (noexcept) ... */ return *this; }
22
};
23
24
int main() {
25
int size = 100000;
26
27
// 测试 non-noexcept 类型
28
std::vector<MyNonNoexceptType> vec1;
29
for (int i = 0; i < size; ++i) {
30
vec1.emplace_back();
31
}
32
auto start_time1 = std::chrono::high_resolution_clock::now();
33
std::sort(vec1.begin(), vec1.end(), [](const MyNonNoexceptType& a, const MyNonNoexceptType& b) {
34
return a.data[0] < b.data[0]; // 简单的比较函数
35
});
36
auto end_time1 = std::chrono::high_resolution_clock::now();
37
auto duration1 = std::chrono::duration_cast<std::chrono::milliseconds>(end_time1 - start_time1);
38
std::cout << "std::sort with MyNonNoexceptType: " << duration1.count() << " ms" << std::endl;
39
40
// 测试 noexcept 类型
41
std::vector<MyNoexceptType> vec2;
42
for (int i = 0; i < size; ++i) {
43
vec2.emplace_back();
44
}
45
auto start_time2 = std::chrono::high_resolution_clock::now();
46
std::sort(vec2.begin(), vec2.end(), [](const MyNoexceptType& a, const MyNoexceptType& b) {
47
return a.data[0] < b.data[0]; // 相同的比较函数
48
});
49
auto end_time2 = std::chrono::high_resolution_clock::now();
50
auto duration2 = std::chrono::duration_cast<std::chrono::milliseconds>(end_time2 - start_time2);
51
std::cout << "std::sort with MyNoexceptType: " << duration2.count() << " ms" << std::endl;
52
53
return 0;
54
}
在这个示例中，MyNoexceptType 和 MyNonNoexceptType 的唯一区别在于移动构造函数和移动赋值运算符是否声明为 noexcept。通过比较使用 std::sort 对这两种类型 std::vector 进行排序的性能，可以观察到 noexcept 移动操作带来的性能提升。在实际运行中，使用 MyNoexceptType 的排序通常会更快，因为 std::sort 可以利用 noexcept 移动操作进行优化。
3.2.4 noexcept 与异常安全 (Exception Safety with noexcept)
noexcept 说明符不仅对性能优化有益，而且在异常安全编程 (exception-safe programming) 中也扮演着至关重要的角色。noexcept 函数的异常行为保证对于编写异常安全的代码至关重要。
① 析构函数必须 noexcept (Destructors Should Be noexcept):
⚝ 避免 std::terminate()： C++ 标准规定，如果在栈展开 (stack unwinding) 过程中，一个析构函数抛出了异常，而此时已经有异常处于活动状态，程序会立即调用 std::terminate() 函数。这通常是不可接受的，因为它会导致程序直接终止，而无法进行正常的错误处理和资源清理。
⚝ 保证资源释放： 析构函数的主要职责是释放对象所拥有的资源。如果析构函数本身抛出异常，可能会导致资源泄漏 (resource leak) 或程序状态不一致。将析构函数声明为 noexcept 可以避免在析构过程中抛出异常，从而保证资源的可靠释放和程序的稳定性。
⚝ 默认 noexcept (Implicit noexcept): 从 C++11 开始，编译器会隐式地将析构函数视为 noexcept(true)，除非析构函数本身或其调用的函数可能抛出异常。尽管如此，显式地将析构函数声明为 noexcept 仍然是一个良好的编程实践 (good practice)，可以提高代码的可读性和清晰度，并强制编译器进行静态检查，确保析构函数不会抛出异常。
② 移动操作应尽可能 noexcept (Move Operations Should Be noexcept When Possible)：
⚝ 强异常安全保证 (Strong Exception Safety Guarantee)： 在某些情况下，为了提供强异常安全保证 (strong exception safety guarantee)，操作必须要么完全成功，要么完全不生效，并且不产生任何副作用。例如，在容器的元素移动或重新分配内存时，如果移动操作是 noexcept 的，容器可以更容易地实现强异常安全保证。
⚝ 标准库容器和算法的要求： 标准库的容器和算法在很多操作中，例如 std::vector::resize(), std::sort(), std::swap() 等，都会依赖于元素的移动操作。为了优化性能和保证异常安全，标准库通常会优先选择 noexcept 的移动操作。如果一个类型的移动操作不是 noexcept 的，标准库可能需要采取更保守的策略，例如使用拷贝操作，或者提供较低的异常安全保证。
⚝ 自定义类型的移动操作： 在设计自定义类型时，如果移动构造函数和移动赋值运算符可以实现为不抛出异常，应该尽可能地将它们声明为 noexcept。这可以提高类型的性能，并使其更好地与标准库容器和算法配合使用。
③ noexcept 函数简化异常处理逻辑 (Simplified Exception Handling Logic)：
⚝ 减少复杂性： 在编写异常处理代码时，如果知道某些函数是 noexcept 的，可以简化异常处理逻辑，减少代码的复杂性。例如，在 catch 块中处理异常时，如果知道某些资源清理操作是通过 noexcept 析构函数进行的，可以减少对资源泄漏的担忧。
⚝ 提高代码可靠性： noexcept 函数的异常行为保证可以提高代码的可靠性。通过明确声明哪些函数不会抛出异常，可以减少程序中潜在的异常传播路径，更容易进行错误分析和调试。
示例 5：noexcept 与析构函数的异常安全
1
#include <iostream>
2
#include <stdexcept>
3
4
class ResourceWrapper {
5
int* resource;
6
public:
7
ResourceWrapper() : resource(new int(42)) {
8
std::cout << "Resource acquired" << std::endl;
9
}
10
~ResourceWrapper() noexcept(false) { // 故意声明为 non-noexcept 析构函数 (不推荐！)
11
std::cout << "Resource releasing..." << std::endl;
12
if (rand() % 2 == 0) {
13
throw std::runtime_error("Exception in destructor!"); // 模拟析构函数抛出异常 (非常不推荐！)
14
}
15
delete resource;
16
std::cout << "Resource released" << std::endl;
17
}
18
19
void useResource() {
20
std::cout << "Using resource: " << *resource << std::endl;
21
}
22
};
23
24
int main() {
25
try {
26
ResourceWrapper wrapper;
27
wrapper.useResource();
28
throw std::runtime_error("Exception in main function!"); // 抛出异常，触发栈展开
29
} catch (const std::exception& e) {
30
std::cerr << "Caught exception: " << e.what() << std::endl;
31
}
32
std::cout << "Program continues after exception handling." << std::endl; // 可能会因为析构函数抛异常而无法执行到这里
33
34
return 0; // 如果析构函数抛出异常，程序可能会在栈展开过程中调用 std::terminate()，导致程序异常终止
35
}
在这个例子中，ResourceWrapper 的析构函数被故意声明为 noexcept(false)，并且在某些情况下会抛出异常 (这是非常不推荐的做法！)。当 main 函数抛出异常时，会触发栈展开，并调用 wrapper 对象的析构函数。如果析构函数也抛出异常，由于此时已经有异常处于活动状态，程序很可能会调用 std::terminate() 而异常终止，而不是继续执行 main 函数中的 catch 块之后的代码。这说明了在析构函数中抛出异常的危险性，以及将析构函数声明为 noexcept 的重要性。
3.3 何时使用 noexcept？(When to Use noexcept?)
noexcept 说明符是一个强大的工具，但并非所有函数都应该声明为 noexcept。合理地使用 noexcept 可以提高性能和代码的异常安全性，而不当使用则可能导致程序行为不符合预期。本节将提供关于何时应该使用 noexcept 的指导原则和建议。
3.3.1 默认应该使用 noexcept 的情况 (Default Cases for Using noexcept)
在以下情况下，默认应该将函数声明为 noexcept：
① 析构函数 (Destructors)：
⚝ 强制性建议： 析构函数必须 (should) 声明为 noexcept。这是异常安全编程的基本原则 (fundamental principle)。
⚝ 避免 std::terminate()： 析构函数抛出异常会导致程序在栈展开过程中异常终止。
⚝ 资源可靠释放： 保证析构函数不抛出异常，是保证资源可靠释放的关键。
⚝ 显式声明： 即使编译器会隐式地将析构函数视为 noexcept(true)，也应该显式 (explicitly) 地声明为 noexcept，以提高代码可读性和清晰度。
② 移动构造函数 (Move Constructors) 和 移动赋值运算符 (Move Assignment Operators)：
⚝ 性能优化： 标准库容器和算法在很多情况下会依赖于 noexcept 移动操作进行性能优化。
⚝ 强异常安全保证： noexcept 移动操作有助于实现强异常安全保证。
⚝ 自定义类型： 如果移动操作可以实现为不抛出异常，应该尽可能地声明为 noexcept。
⚝ 检查类型特性： 可以使用 std::is_nothrow_move_constructible<T>::value 和 std::is_nothrow_move_assignable<T>::value 来检查类型是否具有 noexcept 移动操作。
③ 交换函数 (Swap Functions)：
⚝ 基本操作： swap 函数通常用于交换两个对象的状态，是很多算法和数据结构的基础操作。
⚝ 效率和异常安全： noexcept swap 函数可以提高效率，并简化异常安全编程。
⚝ 自定义类型： 为自定义类型实现 swap 函数时，如果可以实现为不抛出异常，应该声明为 noexcept。
④ 不应该抛出异常的底层工具函数和辅助函数 (Low-Level Utility and Helper Functions That Should Not Throw)：
⚝ 提高性能： 对于一些底层工具函数或辅助函数，如果设计上就不应该抛出异常，可以声明为 noexcept 以提高性能。
⚝ 简化代码逻辑： noexcept 函数可以简化调用者的异常处理逻辑。
⚝ 例如： 简单的数学运算函数、内存操作函数、位操作函数等。
⑤ operator delete 和 operator delete[]:
⚝ 内存释放： operator delete 和 operator delete[] 用于释放动态分配的内存。
⚝ 避免内存泄漏： 内存释放在析构过程中至关重要，应该保证不抛出异常。
⚝ 默认 noexcept: C++11 起，标准库提供的全局 operator delete 和 operator delete[] 都是隐式 noexcept(true) 的。自定义的 operator delete 和 operator delete[] 也应该遵循这个原则。
总结: 在设计和实现类时，要特别注意析构函数、移动操作、交换函数和内存管理函数，尽可能地将它们声明为 noexcept，以提高性能和异常安全性。
3.3.2 不应该使用 noexcept 的情况 (Cases Against Using noexcept)
在以下情况下，不应该或者不应该盲目地使用 noexcept：
① 可能抛出异常的函数 (Functions That May Throw Exceptions)：
⚝ 运行时错误： 如果函数在正常执行过程中可能 (likely) 遇到运行时错误，并需要通过抛出异常来报告错误，不应该 (should not) 将其声明为 noexcept。
⚝ 错误处理： 异常处理机制的目的是处理运行时错误。如果函数的设计意图就是通过异常来传递错误信息，那么它就不是 (not) noexcept 的。
⚝ 例如： 文件 I/O 操作、网络通信操作、动态内存分配 (在某些情况下)、用户输入处理等，这些操作都可能因为各种外部因素而失败，并抛出异常。
② 需要进行错误处理的函数 (Functions That Need to Perform Error Handling)：
⚝ 复杂逻辑： 一些函数可能包含复杂的业务逻辑，需要处理多种可能的错误情况。如果使用异常处理是管理这些错误情况的最佳方式，那么这些函数就不应该 (should not) 被声明为 noexcept。
⚝ 资源管理： 虽然 RAII 可以帮助管理资源，但在某些情况下，函数本身可能需要显式地处理资源分配和释放过程中可能发生的错误。如果错误处理涉及到抛出异常，函数就不应该 (should not) 是 noexcept 的。
③ 不确定是否 noexcept 的函数 (Functions Whose noexcept Status is Uncertain)：
⚝ 依赖于其他可能抛出异常的函数： 如果一个函数内部调用了其他可能抛出异常的函数，并且无法保证在所有情况下都不抛出异常，那么这个函数就不应该 (should not) 被声明为 noexcept。
⚝ 避免违反 noexcept 承诺： 违反 noexcept 承诺会导致程序直接终止，这通常比抛出未捕获异常更糟糕。因此，如果对函数是否真的 noexcept 没有充分的信心 (sufficient confidence)，宁可保守 (better to be conservative)，不要轻易声明为 noexcept。
④ 为了兼容旧代码或库 (For Compatibility with Legacy Code or Libraries)：
⚝ 外部接口： 如果需要与旧的 C++ 代码或 C 语言库进行交互，而这些代码或库的异常行为是不确定的，或者不使用异常处理，那么为了兼容性，可能不应该 (should not) 强制将接口函数声明为 noexcept。
⚝ 保持一致性： 在大型项目中，为了保持代码风格和异常处理策略的一致性，可能需要根据项目已有的代码规范来决定是否使用 noexcept。
误用 noexcept 的风险
⚝ 程序意外终止： 如果错误地将一个可能抛出异常的函数声明为 noexcept，当异常真的抛出时，程序会调用 std::terminate() 异常终止，而不是进行正常的异常处理。这可能会导致数据丢失、状态不一致，甚至安全问题。
⚝ 隐藏潜在错误： 过度使用 noexcept 可能会掩盖 (mask) 程序中潜在的错误。如果一个本应通过异常报告的错误被 noexcept 阻止，可能会导致错误被忽略，并在后续的执行过程中引发更严重的问题。
总结: noexcept 应该谨慎 (cautiously) 使用。只有在确信 (confident) 函数确实不会抛出异常，或者在必须保证 noexcept (例如析构函数、移动操作) 的情况下才应该使用。对于可能抛出异常的函数，或者不确定是否 noexcept 的函数，应该避免 (avoid) 使用 noexcept，或者使用有条件 noexcept 来更精确地描述函数的异常行为。
3.3.3 在接口设计中考虑 noexcept (Considering noexcept in Interface Design)
在设计库 (libraries) 和接口 (interfaces) 时，noexcept 说明符是一个重要的考虑因素。noexcept 声明不仅影响函数的性能，也影响其异常安全性和可用性。良好的接口设计应该明确地考虑函数的异常行为，并合理地使用 noexcept。
① 明确声明异常行为 (Explicitly Declare Exception Behavior)：
⚝ 接口文档： 在库和接口的文档中，应该清晰 (clearly) 地说明每个函数是否可能抛出异常，以及可能抛出的异常类型 (如果适用)。
⚝ noexcept 说明符： 使用 noexcept 说明符在函数签名 (function signature) 中直接 (directly) 声明函数的异常行为。这比仅仅在文档中说明更有效，因为 noexcept 是编译器可检查 (compiler-checkable) 的，可以提供更强的保证。
⚝ 用户预期： 明确声明异常行为可以帮助用户正确 (correctly) 地使用库和接口，并编写更健壮的代码。用户可以根据 noexcept 声明来决定是否需要使用 try-catch 块来处理异常，以及如何进行错误处理。
② 考虑性能与异常安全的权衡 (Trade-off Between Performance and Exception Safety)：
⚝ 性能敏感的接口： 对于性能非常敏感 (performance-critical) 的接口，例如底层数据结构、算法、系统调用接口等，可以考虑尽可能地使用 noexcept。noexcept 可以为编译器提供更多的优化空间，提高性能。
⚝ 异常安全的接口： 对于需要提供高 (high) 异常安全保证的接口，例如事务处理、资源管理、并发编程接口等，也需要仔细考虑 noexcept 的使用。在某些情况下，为了保证强异常安全，可能需要使用 noexcept 移动操作、RAII 等技术。
⚝ 权衡利弊： 在设计接口时，需要在性能 (performance)、异常安全 (exception safety) 和易用性 (usability) 之间进行权衡。没有一种策略是适用于所有情况的。需要根据具体的应用场景和需求来做出合理的选择。
③ 遵循标准库的惯例 (Follow Standard Library Conventions)：
⚝ 参考标准库设计： C++ 标准库是接口设计的典范 (exemplar)。在设计自定义库和接口时，可以参考标准库中 noexcept 的使用惯例。例如，标准库中的移动操作、析构函数、swap 函数等通常都是 noexcept 的，而文件 I/O 操作、网络操作等则不是 noexcept 的。
⚝ 保持一致性： 如果自定义库是 C++ 标准库的扩展或补充，应该尽量保持与标准库在异常处理策略上的一致性。这可以降低用户的学习成本，并提高库的可用性。
④ 提供不同 noexcept 版本的接口 (Provide Different noexcept Versions of Interfaces)：
⚝ 条件 noexcept 接口： 可以使用有条件 noexcept 来提供更灵活的接口。例如，可以提供一个模板函数，其 noexcept 属性取决于模板参数的类型特性。
⚝ 重载 (overload) 或模板特化 (template specialization)： 在某些情况下，可以提供重载 (overloaded) 的函数或者模板特化 (template specializations)，分别提供 noexcept 和 non-noexcept 版本的接口，以满足不同用户的需求。例如，可以提供一个 vector::push_back() 的 noexcept 版本和一个 non-noexcept 版本，让用户根据自己的需求选择使用。
示例 6：接口设计中 noexcept 的考虑
1
#include <iostream>
2
#include <vector>
3
#include <algorithm>
4
5
template <typename T>
6
class SortableVector {
7
std::vector<T> data;
8
public:
9
SortableVector() = default;
10
SortableVector(std::vector<T> init_data) : data(std::move(init_data)) {}
11
12
// 排序函数，如果元素类型的移动构造函数是 noexcept 的，则 SortableVector::sort() 也是 noexcept 的
13
void sort() noexcept(std::is_nothrow_move_constructible<T>::value) {
14
std::sort(data.begin(), data.end()); // std::sort 会利用 noexcept 移动操作进行优化
15
}
16
17
// 添加元素，不保证 noexcept，因为 push_back() 本身可能抛出异常 (例如 std::bad_alloc)
18
void push_back(const T& value) {
19
data.push_back(value);
20
}
21
22
// 移动操作，应该 noexcept
23
SortableVector(SortableVector&& other) noexcept : data(std::move(other.data)) {}
24
SortableVector& operator=(SortableVector&& other) noexcept {
25
data = std::move(other.data);
26
return *this;
27
}
28
29
// 析构函数，必须 noexcept
30
~SortableVector() noexcept = default;
31
32
// ... 其他接口 ...
33
};
34
35
int main() {
36
SortableVector<int> vec1({3, 1, 4, 1, 5, 9, 2, 6});
37
vec1.sort(); // SortableVector<int>::sort() 是 noexcept 的，因为 int 的移动构造函数是 noexcept 的
38
39
SortableVector<std::string> vec2({"banana", "apple", "orange"});
40
vec2.sort(); // SortableVector<std::string>::sort() 不是 noexcept 的，因为 std::string 的移动构造函数不是 noexcept 的 (在某些情况下)
41
42
return 0;
43
}
在这个例子中，SortableVector 类提供了一个 sort() 函数，其 noexcept 属性取决于元素类型 T 的移动构造函数是否是 noexcept 的。这种设计允许 SortableVector 在元素类型支持 noexcept 移动操作时，提供更高效、更异常安全的排序功能。同时，对于其他操作，例如 push_back()，则不强制要求 noexcept，因为这些操作本身可能抛出异常。这种细粒度 (fine-grained) 的 noexcept 控制，是现代 C++ 接口设计的一个重要特点。
4. 异常对象与异常类体系 (Exception Objects and Exception Class Hierarchy)
本章深入探讨异常对象，包括标准异常类体系、自定义异常类的设计，以及异常对象的生命周期和传递。
4.1 标准异常类体系 (Standard Exception Class Hierarchy)
介绍 C++ 标准库提供的异常类体系结构，包括基类 std::exception 和各种派生异常类，如逻辑错误、运行时错误等。
4.1.1 std::exception 基类 (std::exception Base Class)
讲解 std::exception 的接口和作用，以及作为所有标准异常类的基类的意义。
std::exception 是 C++ 标准库中所有标准异常类的基类，它定义了所有标准异常类型都应该具有的通用接口。通过继承 std::exception，自定义异常类可以融入到 C++ 的异常处理框架中，并与标准库提供的异常处理机制良好地兼容。
std::exception 的主要特点和作用：
① 作为基类 (Base Class)：std::exception 作为一个抽象基类，为构建统一的异常处理体系提供了基础。它本身并不表示任何特定的错误，而是作为一种通用的异常类型。
② 虚函数 what() (Virtual Function what())：std::exception 声明了一个重要的虚函数 what()，该函数返回一个 const char* 类型的字符串，用于提供关于异常的描述信息。派生类应该重写 (override) 这个函数，以提供更具体、更有意义的错误信息。
③ 默认构造函数、复制构造函数、赋值运算符和虚析构函数 (Default Constructor, Copy Constructor, Assignment Operator, and Virtual Destructor)：std::exception 提供了这些基本的成员函数，并且析构函数是虚函数，这使得通过基类指针或引用来处理派生类异常成为可能，符合多态 (polymorphism) 的特性。
std::exception 的意义：
⚝ 统一的异常接口：std::exception 提供了一个统一的接口 what()，使得无论抛出的是哪种标准异常，或者自定义异常，都可以通过调用 what() 方法来获取错误描述信息，从而简化了异常处理代码的编写。
⚝ 多态异常处理：由于 std::exception 是一个基类，并且析构函数是虚函数，因此可以使用基类指针或引用来捕获和处理各种派生类型的异常，实现了多态的异常处理。这在编写通用异常处理代码时非常有用，例如，可以编写一个 catch (const std::exception& e) 块来捕获和处理所有继承自 std::exception 的异常。
⚝ 与标准库的兼容性：标准库中许多函数在出错时都会抛出 std::exception 或其派生类的异常。通过继承 std::exception，自定义异常可以无缝地融入到这个体系中，方便与标准库进行交互。
示例代码：
1
#include <iostream>
2
#include <exception>
3
#include <stdexcept>
4
5
int main() {
6
try {
7
// 假设这里可能会抛出异常
8
throw std::runtime_error("A runtime error occurred!");
9
} catch (const std::exception& e) {
10
std::cerr << "Caught exception: " << e.what() << std::endl;
11
} catch (...) {
12
std::cerr << "Caught unknown exception." << std::endl;
13
}
14
return 0;
15
}
在这个例子中，std::runtime_error 是 std::exception 的派生类。catch (const std::exception& e) 块能够捕获 std::runtime_error 类型的异常，并调用 e.what() 输出错误信息。
总而言之，std::exception 是 C++ 标准异常体系的核心，它提供了一个通用的基类和接口，为构建健壮、可维护的异常处理机制奠定了基础。在设计自定义异常类时，通常都应该考虑继承自 std::exception 或其派生类。
4.1.2 逻辑错误类 (std::logic_error Family)
介绍 std::logic_error 及其派生类，如 std::invalid_argument, std::domain_error 等，用于表示程序逻辑错误。
std::logic_error 是 std::exception 的直接派生类，它以及它的派生类主要用于报告程序逻辑上的错误。这类错误通常是可以避免的，例如，违反了函数的前提条件 (precondition)，或者程序的设计存在缺陷。std::logic_error 体系下的异常通常表明程序中存在 bug。
std::logic_error 家族的成员：
① std::logic_error：作为逻辑错误异常的基类。它本身很少被直接抛出，更多地是被用作派生类的基类。
② std::domain_error：当参数值超出了函数或操作的有效定义域时抛出。例如，计算负数的平方根。
③ std::invalid_argument：当传递给函数的参数值是无效的时抛出，但并不属于 std::domain_error 的情况。例如，当函数期望一个非空字符串，但却接收到了空字符串。
④ std::length_error：当试图创建长度超过最大允许值的对象时抛出。例如，试图创建一个过长的 std::string 或 std::vector。
⑤ std::out_of_range：当试图访问超出有效范围的元素时抛出。例如，访问 std::vector 或 std::string 的越界索引。
⑥ std::future_error (虽然名字没有 "logic_error"，但概念上属于逻辑错误)：与 std::future 和异步操作相关的错误，例如，试图在 future 对象上获取一个已经获取过的值。
使用场景和示例：
⚝ std::domain_error 示例：
1
#include <iostream>
2
#include <stdexcept>
3
#include <cmath>
4
5
double safe_sqrt(double x) {
6
if (x < 0.0) {
7
throw std::domain_error("Cannot take square root of a negative number");
8
}
9
return std::sqrt(x);
10
}
11
12
int main() {
13
try {
14
double result = safe_sqrt(-1.0);
15
std::cout << "Square root is: " << result << std::endl; // 不会执行到这里
16
} catch (const std::domain_error& e) {
17
std::cerr << "Domain error caught: " << e.what() << std::endl;
18
}
19
return 0;
20
}
⚝ std::invalid_argument 示例：
1
#include <iostream>
2
#include <stdexcept>
3
#include <string>
4
5
void process_string(const std::string& str) {
6
if (str.empty()) {
7
throw std::invalid_argument("Input string cannot be empty");
8
}
9
std::cout << "Processing string: " << str << std::endl;
10
}
11
12
int main() {
13
try {
14
process_string("");
15
} catch (const std::invalid_argument& e) {
16
std::cerr << "Invalid argument caught: " << e.what() << std::endl;
17
}
18
return 0;
19
}
⚝ std::out_of_range 示例：
1
#include <iostream>
2
#include <stdexcept>
3
#include <vector>
4
5
int main() {
6
std::vector<int> vec = {1, 2, 3};
7
try {
8
int value = vec.at(5); // 使用 at() 会进行边界检查，越界会抛出 std::out_of_range
9
std::cout << "Value at index 5: " << value << std::endl; // 不会执行到这里
10
} catch (const std::out_of_range& e) {
11
std::cerr << "Out of range error caught: " << e.what() << std::endl;
12
}
13
return 0;
14
}
总结 std::logic_error 家族：
std::logic_error 及其派生类提供了一组标准的异常类型，用于报告程序逻辑上的错误。它们帮助开发者更清晰地表达程序中出现的逻辑问题，并鼓励在开发阶段就尽早发现和修复这些错误。使用这些标准异常类可以提高代码的可读性和可维护性，并使得异常处理更加规范化。
4.1.3 运行时错误类 (std::runtime_error Family)
介绍 std::runtime_error 及其派生类，如 std::overflow_error, std::underflow_error 等，用于表示运行时错误。
std::runtime_error 也是 std::exception 的直接派生类，它以及它的派生类用于报告程序在运行时才可能发生的错误。这类错误通常是不可预见的，并且往往不是由程序逻辑错误直接导致的，而是由外部环境或不可控因素引起的。例如，系统资源耗尽、硬件故障、网络错误等。
std::runtime_error 家族的成员：
① std::runtime_error：作为运行时错误异常的基类。类似于 std::logic_error，它本身也较少被直接抛出，更多地作为派生类的基类。
② std::overflow_error：当算术运算产生上溢 (overflow) 时抛出，即结果值超出了目标类型的表示范围。
③ std::underflow_error：当算术运算产生下溢 (underflow) 时抛出，即结果值太小，以至于无法精确表示，或者比目标类型能表示的最小值还小。
④ std::range_error：当计算结果超出了有效范围，但又不属于上溢或下溢的情况时抛出。这个异常类型的使用相对较少，其界定有时与 std::overflow_error 和 std::underflow_error 有些模糊。
⑤ std::system_error (虽然名字没有 "runtime_error"，但概念上属于运行时错误)：与操作系统相关的错误，例如文件 I/O 错误、网络错误等。std::system_error 实际上比较特殊，它继承自 std::runtime_error，但同时也关联一个 std::error_code 对象，提供更详细的系统错误信息。
⑥ std::filesystem::filesystem_error (C++17 引入，概念上属于运行时错误)：专门用于文件系统操作可能产生的错误，继承自 std::system_error。
使用场景和示例：
⚝ std::overflow_error 示例：
1
#include <iostream>
2
#include <stdexcept>
3
#include <limits>
4
5
int main() {
6
try {
7
short max_short = std::numeric_limits<short>::max();
8
short result = max_short + 1; // 可能会发生溢出
9
if (result < max_short) { // 一种简单的溢出检测方法，但不是所有情况都适用
10
throw std::overflow_error("Short integer overflow occurred");
11
}
12
std::cout << "Result: " << result << std::endl; // 不会执行到这里
13
} catch (const std::overflow_error& e) {
14
std::cerr << "Overflow error caught: " << e.what() << std::endl;
15
}
16
return 0;
17
}
⚝ std::underflow_error 示例 (注意：std::underflow_error 在整数运算中较少见，更多出现在浮点数运算中，但标准库对整数溢出和下溢的行为通常是未定义的，不一定会抛出异常。以下示例更侧重概念演示)：
1
#include <iostream>
2
#include <stdexcept>
3
#include <limits>
4
#include <cmath>
5
6
int main() {
7
try {
8
double min_double = std::numeric_limits<double>::min(); // 最小正浮点数
9
double result = min_double / 10.0; // 可能发生下溢
10
if (result == 0.0 && min_double != 0.0) { // 下溢的一种简单检测方法，可能不完全准确
11
throw std::underflow_error("Double underflow occurred");
12
}
13
std::cout << "Result: " << result << std::endl;
14
} catch (const std::underflow_error& e) {
15
std::cerr << "Underflow error caught: " << e.what() << std::endl;
16
}
17
return 0;
18
}
⚝ std::system_error 示例 (文件 I/O 错误)：
1
#include <iostream>
2
#include <fstream>
3
#include <stdexcept>
4
5
int main() {
6
try {
7
std::ifstream file("nonexistent_file.txt");
8
if (!file.is_open()) {
9
throw std::system_error(errno, std::generic_category(), "Failed to open file"); // 使用 errno 和 generic_category 获取系统错误信息
10
}
11
// ... 文件操作 ...
12
} catch (const std::system_error& e) {
13
std::cerr << "System error caught: " << e.what() << " Error code: " << e.code() << std::endl;
14
}
15
return 0;
16
}
总结 std::runtime_error 家族：
std::runtime_error 及其派生类用于报告运行时错误，这类错误通常是外部因素导致的，程序逻辑本身可能没有问题。使用 std::runtime_error 家族的异常可以帮助区分逻辑错误和运行时错误，使得错误处理更加精细化。特别是 std::system_error，它提供了访问底层系统错误代码的能力，对于处理操作系统相关的错误非常有用。
4.1.4 其他标准异常类 (Other Standard Exception Classes)
简要介绍其他标准异常类，如 std::bad_alloc, std::bad_cast, std::bad_typeid 等。
除了 std::logic_error 和 std::runtime_error 家族，C++ 标准库还定义了一些其他的异常类，它们在特定的场景下被抛出，用于报告特定类型的错误。这些异常类也都继承自 std::exception (或其派生类)。
① std::bad_alloc：当内存分配失败时，例如 new 运算符无法分配请求的内存时，会抛出 std::bad_alloc 异常。这通常发生在系统内存耗尽的情况下。
② std::bad_cast：当使用 dynamic_cast 进行向下转型 (downcast)，但转型操作不合法时（即，指针或引用实际上并不指向目标类型或其派生类），会抛出 std::bad_cast 异常。这仅在对引用类型进行 dynamic_cast 失败时抛出；对指针类型进行 dynamic_cast 失败会返回空指针 nullptr，而不是抛出异常。
③ std::bad_typeid：当对空指针 (null pointer) 应用 typeid 运算符时，会抛出 std::bad_typeid 异常。typeid 用于获取对象的运行时类型信息，但对空指针无法获取有效的类型信息。
④ std::bad_function_call (C++11 引入)：当尝试调用一个空的 std::function 对象时，会抛出 std::bad_function_call 异常。std::function 是一种通用的函数包装器，如果它没有绑定任何可调用的目标 (函数、函数对象、lambda 表达式等)，则称其为空。
⑤ std::ios_base::failure：与 I/O 流操作相关的错误。std::ios_base::failure 是 std::system_error 的派生类，当 I/O 流遇到错误状态 (例如，读取文件结束符，格式错误等)，并且流的异常掩码 (exception mask) 设置为抛出异常时，会抛出 std::ios_base::failure 异常。
⑥ std::nested_exception (C++11 引入)：用于支持嵌套异常。std::nested_exception 类本身并不表示特定的错误，而是一种异常包装器，它可以捕获当前异常，并在稍后重新抛出，常用于实现异常的链式传递和处理。
示例代码：
⚝ std::bad_alloc 示例：
1
#include <iostream>
2
#include <new> // 包含 std::bad_alloc
3
4
int main() {
5
try {
6
// 尝试分配大量内存，可能会导致 bad_alloc
7
char* huge_memory = new char[SIZE_MAX]; // SIZE_MAX 是一个很大的值
8
// ... 使用内存 ...
9
delete[] huge_memory;
10
} catch (const std::bad_alloc& e) {
11
std::cerr << "Memory allocation failed: " << e.what() << std::endl;
12
}
13
return 0;
14
}
⚝ std::bad_cast 示例：
1
#include <iostream>
2
#include <stdexcept>
3
4
class Base { virtual void foo() {} };
5
class Derived : public Base { void foo() override {} };
6
class Another {};
7
8
int main() {
9
Base* base_ptr = new Base();
10
try {
11
Derived& derived_ref = dynamic_cast<Derived&>(*base_ptr); // 尝试将 Base* 转换为 Derived&，但 base_ptr 实际指向的是 Base 对象，转型失败
12
// ... 使用 derived_ref ... (不会执行到这里)
13
} catch (const std::bad_cast& e) {
14
std::cerr << "Bad cast exception caught: " << e.what() << std::endl;
15
}
16
delete base_ptr;
17
return 0;
18
}
⚝ std::bad_typeid 示例：
1
#include <iostream>
2
#include <stdexcept>
3
#include <typeinfo>
4
5
class Base { virtual void foo() {} };
6
7
int main() {
8
Base* base_ptr = nullptr;
9
try {
10
const std::type_info& type_info = typeid(*base_ptr); // 对空指针解引用，typeid 无法获取类型信息
11
std::cout << "Type: " << type_info.name() << std::endl; // 不会执行到这里
12
} catch (const std::bad_typeid& e) {
13
std::cerr << "Bad typeid exception caught: " << e.what() << std::endl;
14
}
15
return 0;
16
}
⚝ std::bad_function_call 示例：
1
#include <iostream>
2
#include <functional>
3
#include <stdexcept>
4
5
int main() {
6
std::function<void()> func; // 创建一个空的 std::function 对象
7
try {
8
func(); // 尝试调用空的 std::function 对象
9
} catch (const std::bad_function_call& e) {
10
std::cerr << "Bad function call exception caught: " << e.what() << std::endl;
11
}
12
return 0;
13
}
总结其他标准异常类：
这些其他的标准异常类，各自代表了 C++ 程序中可能发生的特定类型的错误情况。了解和使用这些标准异常类，可以帮助开发者更精确地处理各种异常情况，并编写更加健壮和可靠的 C++ 程序。在适当的场景下抛出和捕获这些标准异常，是符合 C++ 异常处理规范的做法。
4.2 自定义异常类的设计 (Designing Custom Exception Classes)
指导读者如何设计和实现自定义异常类，以满足特定应用程序的错误处理需求。
在很多情况下，标准异常类可能无法完全满足特定应用程序的错误处理需求。这时，就需要设计和实现自定义的异常类。自定义异常类可以更精确地表达应用程序特有的错误情况，并携带更多的错误信息，从而使得异常处理更加有效和方便。
4.2.1 继承自 std::exception (Inheriting from std::exception)
强调自定义异常类应该继承自 std::exception 或其派生类，以保持与标准异常体系的一致性。
为什么要继承自 std::exception？
① 兼容性与一致性 (Compatibility and Consistency)：继承自 std::exception 可以使自定义异常类融入到 C++ 标准的异常处理体系中。这样，你的自定义异常就可以被 catch (const std::exception& e) 这样的通用 catch 块捕获和处理，保证了代码的兼容性和一致性。
② 接口统一 (Unified Interface)：std::exception 提供了 what() 虚函数，要求所有派生类都应该提供一个返回错误描述信息的接口。继承 std::exception 并重写 what() 方法，可以确保你的自定义异常也具有这个标准的错误信息接口，方便错误信息的获取和展示。
③ 多态性 (Polymorphism)：由于 std::exception 是一个基类，并且析构函数是虚函数，通过继承它可以实现多态的异常处理。你可以使用基类指针或引用来处理各种自定义异常，提高了代码的灵活性和可扩展性。
④ 标准库互操作性 (Standard Library Interoperability)：C++ 标准库的很多组件在出错时会抛出 std::exception 或其派生类的异常。通过继承 std::exception，你的自定义异常可以更好地与标准库协同工作，例如，可以被标准库的异常处理工具函数处理。
继承方式：
通常，自定义异常类应该公有继承 (public inheritance) 自 std::exception 或其派生类。例如，如果你的自定义异常表示一种逻辑错误，可以考虑继承自 std::logic_error；如果表示运行时错误，可以继承自 std::runtime_error。如果你的异常类型不属于逻辑错误或运行时错误的范畴，直接继承自 std::exception 也是一个合理的选择。
示例代码：
1
#include <iostream>
2
#include <exception>
3
#include <string>
4
5
// 自定义异常类，继承自 std::exception
6
class MyCustomException : public std::exception {
7
public:
8
MyCustomException(const std::string& message) : message_(message) {}
9
const char* what() const noexcept override {
10
return message_.c_str();
11
}
12
private:
13
std::string message_;
14
};
15
16
void do_something(int value) {
17
if (value < 0) {
18
throw MyCustomException("Value cannot be negative"); // 抛出自定义异常
19
}
20
// ... 正常操作 ...
21
std::cout << "Processing value: " << value << std::endl;
22
}
23
24
int main() {
25
try {
26
do_something(-5);
27
} catch (const MyCustomException& e) {
28
std::cerr << "Custom exception caught: " << e.what() << std::endl;
29
} catch (const std::exception& e) { // 也可以捕获基类异常
30
std::cerr << "Standard exception caught: " << e.what() << std::endl;
31
}
32
return 0;
33
}
在这个例子中，MyCustomException 继承自 std::exception，并重写了 what() 方法。在 main() 函数中，既可以 catch (const MyCustomException& e) 精确捕获自定义异常，也可以 catch (const std::exception& e) 捕获基类异常。
总结继承自 std::exception：
继承自 std::exception 是设计自定义异常类的最佳实践。它确保了自定义异常与 C++ 标准异常处理体系的兼容性，提供了统一的接口，支持多态处理，并能更好地与标准库协同工作。在设计自定义异常类时，优先考虑继承自 std::exception 或其合适的派生类。
4.2.2 添加额外的错误信息 (Adding Extra Error Information)
讲解如何在自定义异常类中添加额外的错误信息，例如错误代码、错误描述、发生错误的文件和行号等。
除了标准的错误描述信息（通过 what() 方法获取），自定义异常类通常需要携带更多的、应用程序特定的错误信息，以便于错误诊断、日志记录和后续处理。这些额外信息可以包括：
① 错误代码 (Error Code)：一个数字或枚举值，用于唯一标识错误类型。错误代码可以方便程序进行自动化错误分类和处理。
② 详细错误描述 (Detailed Error Description)：更详细的错误信息，可能比 what() 返回的字符串更丰富，例如，包含具体的错误参数、状态信息等。
③ 错误发生的位置 (Error Location)：发生错误的文件名、行号、函数名等信息。这对于定位错误在代码中的位置非常有用，尤其是在大型项目中。
④ 时间戳 (Timestamp)：错误发生的时间。对于日志记录和错误追踪非常重要。
⑤ 其他上下文信息 (Contextual Information)：根据具体应用场景，可能需要添加其他上下文信息，例如，用户 ID、请求 ID、事务 ID 等，帮助理解错误发生的背景。
实现方式：
在自定义异常类中，可以添加成员变量来存储这些额外的信息，并在构造函数中初始化它们。同时，可以提供相应的访问器 (getter) 方法来获取这些信息。
示例代码：
1
#include <iostream>
2
#include <exception>
3
#include <string>
4
#include <chrono> // 时间戳
5
#include <sstream> // 格式化字符串
6
7
// 自定义异常类，携带额外错误信息
8
class FileIOException : public std::runtime_error {
9
public:
10
enum ErrorCode {
11
FILE_NOT_FOUND,
12
PERMISSION_DENIED,
13
DISK_FULL,
14
UNKNOWN_IO_ERROR
15
};
16
17
FileIOException(ErrorCode code, const std::string& filename, const std::string& operation, const std::string& message, const char* file, int line)
18
: std::runtime_error(message), // 调用基类构造函数，设置 what() 返回的信息
19
error_code_(code),
20
filename_(filename),
21
operation_(operation),
22
file_(file),
23
line_(line),
24
timestamp_(std::chrono::system_clock::now()) {}
25
26
ErrorCode getErrorCode() const { return error_code_; }
27
const std::string& getFilename() const { return filename_; }
28
const std::string& getOperation() const { return operation_; }
29
const char* getFile() const { return file_; }
30
int getLine() const { return line_; }
31
std::chrono::system_clock::time_point getTimestamp() const { return timestamp_; }
32
33
const char* what() const noexcept override { // 重写 what() 方法，包含更多信息
34
std::ostringstream oss;
35
oss << std::runtime_error::what() << " (Error Code: " << error_code_ << ", Filename: " << filename_ << ", Operation: " << operation_
36
<< ", Location: " << file_ << ":" << line_ << ")";
37
return oss.str().c_str();
38
}
39
40
private:
41
ErrorCode error_code_;
42
std::string filename_;
43
std::string operation_;
44
const char* file_; // 发生错误的文件名
45
int line_; // 发生错误的行号
46
std::chrono::system_clock::time_point timestamp_; // 错误发生的时间戳
47
};
48
49
void read_file(const std::string& filename) {
50
// 模拟文件操作，假设文件不存在
51
bool file_exists = false;
52
if (!file_exists) {
53
throw FileIOException(FileIOException::ErrorCode::FILE_NOT_FOUND, filename, "read", "File not found", __FILE__, __LINE__);
54
}
55
// ... 文件读取操作 ...
56
}
57
58
int main() {
59
try {
60
read_file("config.txt");
61
} catch (const FileIOException& e) {
62
std::cerr << "File IO Exception caught: " << e.what() << std::endl;
63
std::cerr << " Error Code: " << e.getErrorCode() << std::endl;
64
std::cerr << " Filename: " << e.getFilename() << std::endl;
65
std::cerr << " Operation: " << e.getOperation() << std::endl;
66
std::cerr << " Location: " << e.getFile() << ":" << e.getLine() << std::endl;
67
std::cerr << " Timestamp: " << std::chrono::system_clock::to_time_t(e.getTimestamp()) << std::endl;
68
} catch (const std::exception& e) {
69
std::cerr << "Standard exception caught: " << e.what() << std::endl;
70
}
71
return 0;
72
}
在这个例子中，FileIOException 类继承自 std::runtime_error，并添加了错误代码、文件名、操作类型、文件位置、时间戳等额外信息。what() 方法也被重写，将这些额外信息也包含在错误描述字符串中。在 catch 块中，可以通过访问器方法获取这些详细信息，进行更全面的错误处理和日志记录。
使用宏简化错误位置信息的添加：
为了方便地获取错误发生的文件名和行号，可以使用宏 (macro) 来简化代码：
1
#define THROW_FILE_IO_EXCEPTION(code, filename, operation, message) throw FileIOException(code, filename, operation, message, __FILE__, __LINE__)
2
3
void read_file(const std::string& filename) {
4
bool file_exists = false;
5
if (!file_exists) {
6
THROW_FILE_IO_EXCEPTION(FileIOException::ErrorCode::FILE_NOT_FOUND, filename, "read", "File not found");
7
}
8
// ...
9
}
总结添加额外错误信息：
在自定义异常类中添加额外的错误信息，可以极大地提升异常处理的实用性。错误代码方便程序进行自动化处理，详细描述和位置信息有助于开发者快速定位和理解错误，时间戳对于日志记录和追踪错误至关重要。根据应用程序的具体需求，可以灵活地添加各种有用的错误信息到自定义异常类中。
4.2.3 提供有意义的 what() 方法 (Providing a Meaningful what() Method)
说明 what() 方法的重要性，以及如何实现一个清晰、有用的 what() 方法来描述异常信息。
what() 方法是 std::exception 类中定义的虚函数，它的作用是返回一个描述异常信息的 C 风格字符串 (const char*)。对于自定义异常类，重写 (override) what() 方法至关重要，因为它提供了一种标准的方式来获取异常的基本描述信息。一个有意义的 what() 方法应该能够简洁、清晰地概括异常的类型和原因，帮助开发者快速理解发生了什么错误。
what() 方法的重要性：
① 标准接口 (Standard Interface)：what() 方法是 std::exception 体系的一部分，是获取异常描述信息的标准方式。遵循这个标准，可以保证代码的一致性和可读性。
② 通用错误输出 (General Error Output)：很多通用的异常处理代码 (例如，顶层的异常捕获和日志记录) 都会依赖 what() 方法来输出错误信息。提供有意义的 what() 方法，可以确保这些通用处理代码能够正确地工作。
③ 调试和日志 (Debugging and Logging)：what() 方法返回的字符串通常会被用于错误日志、调试信息输出等场景。一个清晰的 what() 字符串可以大大提高调试效率，并为错误分析提供有价值的信息。
如何实现有意义的 what() 方法：
① 简洁明了 (Concise and Clear)：what() 方法返回的字符串应该简洁明了，避免过于冗长或晦涩。目标是让读者在第一眼看到这个字符串时，就能大致理解异常的类型和原因。
② 包含关键信息 (Include Key Information)：what() 字符串应该包含描述异常的关键信息。例如，对于文件 I/O 异常，可以包含文件名、操作类型、错误原因等；对于网络异常，可以包含主机地址、端口号、错误类型等。
③ 使用 std::ostringstream 格式化 (Use std::ostringstream for Formatting)：为了方便地构建包含多个信息片段的 what() 字符串，可以使用 std::ostringstream 来进行格式化。这比手动拼接 C 风格字符串更安全、更方便。
④ 考虑国际化 (Consider Internationalization)：如果你的程序需要支持多语言，what() 方法返回的字符串可能需要考虑国际化 (i18n)。一种方法是 what() 方法返回一个通用的、语言无关的错误代码，然后由上层代码根据当前语言环境将错误代码转换为用户可见的错误消息。或者，直接在 what() 方法中根据语言环境返回不同语言的错误消息 (虽然这会增加实现的复杂性)。
⑤ 避免抛出异常 (Noexcept)：what() 方法应该声明为 noexcept，保证它不会抛出异常。因为 what() 方法通常在异常处理流程中使用，如果在 what() 方法中又抛出异常，可能会导致程序崩溃或进入未定义行为。
示例代码 (改进 FileIOException 的 what() 方法)：
1
#include <iostream>
2
#include <exception>
3
#include <string>
4
#include <sstream> // ostringstream
5
6
class FileIOException : public std::runtime_error {
7
// ... (其他成员不变)
8
9
public:
10
// ... (构造函数不变)
11
12
const char* what() const noexcept override {
13
std::ostringstream oss;
14
oss << "File I/O Error: "; // 更加明确的异常类型前缀
15
switch (error_code_) {
16
case ErrorCode::FILE_NOT_FOUND:
17
oss << "File not found: ";
18
break;
19
case ErrorCode::PERMISSION_DENIED:
20
oss << "Permission denied when accessing file: ";
21
break;
22
case ErrorCode::DISK_FULL:
23
oss << "Disk full when writing to file: ";
24
break;
25
case ErrorCode::UNKNOWN_IO_ERROR:
26
default:
27
oss << "Unknown I/O error on file: ";
28
break;
29
}
30
oss << filename_ << ". Operation: " << operation_ << ". Location: " << file_ << ":" << line_;
31
return oss.str().c_str();
32
}
33
// ... (其他方法不变)
34
};
在这个改进的 what() 方法中，首先添加了 "File I/O Error: " 前缀，更明确地表明了异常类型。然后，根据不同的错误代码，输出了更具体的错误原因描述 (例如，"File not found: ", "Permission denied when accessing file: ")。最后，仍然包含了文件名、操作类型和位置信息。这样的 what() 字符串更加清晰、更有信息量。
总结有意义的 what() 方法：
提供一个有意义的 what() 方法是设计自定义异常类的重要环节。它应该简洁、清晰地概括异常的关键信息，使用 std::ostringstream 进行格式化，并考虑国际化和异常安全性。一个好的 what() 方法可以大大提高异常处理代码的可读性、可维护性和调试效率。
4.2.4 异常类的设计原则 (Design Principles for Exception Classes)
总结设计异常类的一些通用原则，例如简洁性、信息量、易用性等。
设计良好的异常类是构建健壮、可维护的 C++ 应用程序的关键。以下是一些设计异常类的通用原则：
① 继承自 std::exception 或其派生类 (Inherit from std::exception or its derivatives)：
▮▮▮▮⚝ 确保自定义异常与 C++ 标准异常体系兼容。
▮▮▮▮⚝ 利用 std::exception 提供的标准接口和多态特性。
② 提供有意义的 what() 方法 (Provide a meaningful what() method)：
▮▮▮▮⚝ what() 方法应该返回简洁、清晰、信息丰富的错误描述字符串。
▮▮▮▮⚝ 使用 std::ostringstream 进行格式化，方便构建复杂的描述信息。
▮▮▮▮⚝ 考虑国际化和异常安全性 (noexcept)。
③ 根据需要添加额外的错误信息 (Add extra error information as needed)：
▮▮▮▮⚝ 添加错误代码、详细描述、位置信息、时间戳等，提供更丰富的错误上下文。
▮▮▮▮⚝ 使用访问器方法 (getter) 获取这些额外信息。
▮▮▮▮⚝ 考虑使用宏简化错误位置信息的添加。
④ 保持异常类的简洁性 (Keep exception classes concise)：
▮▮▮▮⚝ 异常类应该专注于表示错误信息，避免包含过多的业务逻辑或状态。
▮▮▮▮⚝ 避免在异常类中进行复杂的资源管理或操作，这些应该由 RAII 机制处理。
⑤ 异常类命名要清晰、具有描述性 (Use clear and descriptive names for exception classes)：
▮▮▮▮⚝ 异常类的名称应该明确地表明所表示的错误类型。
▮▮▮▮⚝ 遵循命名约定，例如，使用 Exception 后缀 (如 FileNotFoundException, NetworkConnectionException)。
⑥ 设计异常类层次结构 (Design exception class hierarchy if needed)：
▮▮▮▮⚝ 如果应用程序有复杂的错误分类需求，可以设计异常类的继承层次结构。
▮▮▮▮⚝ 例如，可以定义一个通用的 DatabaseException 基类，然后派生出 ConnectionException, QueryException, TransactionException 等更具体的异常类。
▮▮▮▮⚝ 层次结构应该合理、易于理解和维护。
⑦ 考虑异常的粒度 (Consider the granularity of exceptions)：
▮▮▮▮⚝ 异常的粒度应该适中。过于粗粒度的异常可能无法提供足够的信息，过于细粒度的异常可能导致 catch 块过于复杂。
▮▮▮▮⚝ 根据应用程序的错误处理需求和代码复杂性，选择合适的异常粒度。
⑧ 文档化异常类 (Document exception classes)：
▮▮▮▮⚝ 清晰地文档化每个自定义异常类的用途、抛出条件、携带的信息等。
▮▮▮▮⚝ 方便其他开发者理解和使用这些异常类。
⑨ 测试异常处理代码 (Test exception handling code)：
▮▮▮▮⚝ 编写单元测试来验证异常处理代码的正确性，包括异常的抛出、捕获、处理、错误信息的正确性等。
▮▮▮▮⚝ 确保异常处理代码能够有效地处理各种错误情况，并保证程序的健壮性。
总结异常类设计原则：
遵循这些设计原则，可以帮助开发者创建高质量的自定义异常类，提升 C++ 应用程序的错误处理能力和代码质量。良好的异常类设计不仅能够提高代码的可读性和可维护性，还能增强程序的健壮性和可靠性，降低错误处理的复杂性。
4.3 异常对象的生命周期与传递 (Lifetime and Propagation of Exception Objects)
解释异常对象的生命周期，以及异常是如何在调用栈中传递和传播的。
理解异常对象的生命周期和传播机制，对于编写正确的异常处理代码至关重要。当异常被抛出时，会发生一系列复杂的过程，包括异常对象的构造、栈展开、异常传播和最终的捕获处理。
4.3.1 异常对象的构造与析构 (Construction and Destruction of Exception Objects)
分析异常对象的构造和析构过程，以及在异常处理过程中可能发生的资源泄漏问题。
异常对象的构造 (Construction of Exception Objects)：
当 throw 表达式被执行时，首先会根据 throw 后面表达式的值创建一个异常对象。这个对象的类型就是 throw 表达式的操作数类型。例如，如果 throw std::runtime_error("Error message"); 被执行，就会创建一个 std::runtime_error 类型的临时对象。
⚝ 复制构造 (Copy Construction)：通常情况下，异常对象是通过复制构造 (copy construction) 来创建的。这意味着 throw 表达式的操作数会被复制到异常处理系统内部管理的内存区域。因此，作为异常抛出的对象必须是可复制构造的 (copy-constructible)。
⚝ 移动构造 (Move Construction) (C++11 及以后)：在支持移动语义 (move semantics) 的 C++ 版本中，如果抛出的对象是可移动构造的 (move-constructible)，并且 throw 表达式的操作数是一个右值 (rvalue)，则可能会使用移动构造 (move construction) 来创建异常对象，以提高效率。但即使支持移动构造，复制构造仍然是必须的，因为在某些情况下 (例如，抛出的是左值)，仍然会使用复制构造。
⚝ 异常对象的生命周期开始 (Start of Lifetime)：异常对象的生命周期从它被构造出来时开始。
异常对象的析构 (Destruction of Exception Objects)：
异常对象在被 catch 块处理完毕后，或者在栈展开 (stack unwinding) 过程中，最终会被析构 (destroyed)。
⚝ 析构时机 (Timing of Destruction)：
▮▮▮▮⚝ 如果异常被某个 catch 块成功捕获并处理，那么在 catch 块执行完毕后，异常对象会被析构。
▮▮▮▮⚝ 如果异常一直没有被捕获，导致程序终止 (例如，调用 std::terminate)，那么异常对象也会在程序终止前被析构 (尽管这种情况下的析构可能不太重要，因为程序已经要结束了)。
▮▮▮▮⚝ 在栈展开过程中，如果异常沿着调用栈向上传播，但还没有被 catch 块捕获，异常对象会一直存活，直到被捕获或程序终止。
⚝ 析构函数的调用 (Destructor Invocation)：异常对象的析构函数 (destructor) 会在对象被析构时被调用。这对于资源管理非常重要，因为异常对象可能持有资源 (例如，动态分配的内存、文件句柄等)。异常对象的析构函数应该负责释放这些资源，以避免资源泄漏。
资源泄漏问题 (Resource Leakage Issues)：
在异常处理过程中，如果异常对象的构造或析构函数本身抛出异常，可能会导致严重的问题，甚至程序崩溃。尤其是在析构函数中抛出异常，在栈展开过程中会导致 std::terminate 被调用，程序立即终止。
⚝ 构造函数中的异常 (Exceptions in Constructors)：如果在异常对象的构造函数中抛出异常，那么异常对象将无法成功创建。这通常不会直接导致资源泄漏，因为对象本身就没有创建成功。但是，构造函数中抛出异常可能表明程序逻辑或资源分配存在问题。
⚝ 析构函数中的异常 (Exceptions in Destructors)：绝对禁止在析构函数中抛出异常。如果在析构函数中抛出异常，并且此时程序正处于栈展开过程中 (例如，因为之前抛出了另一个异常)，那么 C++ 运行时系统会调用 std::terminate，导致程序立即终止。这会使得异常处理机制失效，并可能导致资源泄漏。因此，析构函数应该设计为不抛出异常，或者在析构函数内部捕获并处理任何可能发生的异常，但绝对不能让异常逃逸出析构函数。
RAII 与异常安全 (RAII and Exception Safety)：
为了避免资源泄漏，并确保异常安全，C++ 中提倡使用 RAII (Resource Acquisition Is Initialization) 惯用法。RAII 的核心思想是将资源的生命周期与对象的生命周期绑定。资源在对象的构造函数中获取，在析构函数中释放。由于 C++ 保证在栈展开时，局部对象的析构函数会被正确调用，因此使用 RAII 可以确保即使在异常发生的情况下，资源也能够被正确释放，避免资源泄漏。
示例代码 (RAII 防止资源泄漏)：
1
#include <iostream>
2
#include <fstream>
3
#include <stdexcept>
4
5
// RAII 类，用于管理文件资源
6
class FileGuard {
7
public:
8
FileGuard(const std::string& filename) : file_(filename.c_str()) {
9
if (!file_.is_open()) {
10
throw std::runtime_error("Failed to open file: " + filename);
11
}
12
std::cout << "File opened: " << filename << std::endl;
13
}
14
~FileGuard() {
15
if (file_.is_open()) {
16
file_.close();
17
std::cout << "File closed." << std::endl;
18
}
19
}
20
std::ifstream& getFileStream() { return file_; }
21
22
private:
23
std::ifstream file_;
24
};
25
26
void process_file(const std::string& filename) {
27
FileGuard file_guard(filename); // RAII 对象，文件在构造函数中打开
28
std::ifstream& file = file_guard.getFileStream();
29
std::string line;
30
while (std::getline(file, line)) {
31
std::cout << "Read line: " << line << std::endl;
32
if (line == "error") {
33
throw std::runtime_error("Error line encountered!"); // 模拟处理错误
34
}
35
}
36
// file_guard 对象超出作用域，析构函数会被调用，文件会被自动关闭
37
}
38
39
int main() {
40
try {
41
process_file("example.txt");
42
} catch (const std::exception& e) {
43
std::cerr << "Exception caught: " << e.what() << std::endl;
44
}
45
return 0;
46
}
在这个例子中，FileGuard 类是一个 RAII 类，它在构造函数中打开文件，在析构函数中关闭文件。即使在 process_file 函数中抛出异常，file_guard 对象超出作用域时，其析构函数仍然会被调用，文件资源会被正确释放，避免了资源泄漏。
总结异常对象的构造与析构：
异常对象的构造通常通过复制或移动构造完成，析构函数在异常处理完毕或栈展开时被调用。析构函数对于资源管理至关重要，但绝对不能抛出异常。使用 RAII 惯用法可以有效地管理资源，并确保在异常发生时资源能够被正确释放，避免资源泄漏，实现异常安全的代码。
4.3.2 栈展开 (Stack Unwinding)
详细解释栈展开的过程，包括局部对象的析构顺序、以及栈展开对性能的影响。
什么是栈展开 (What is Stack Unwinding?)：
栈展开是当异常被抛出但没有被当前的 try-catch 块捕获时，C++ 运行时系统执行的一个过程。它的目的是在异常传播到能够处理它的 catch 块之前，清理调用栈 (call stack) 上已分配的资源，特别是局部对象 (local objects)。
栈展开的过程：
当异常在某个函数中被 throw 抛出，但该函数没有 try-catch 块来捕获这个异常时，栈展开过程开始：
① 查找 catch 块 (Searching for a Catch Handler)：运行时系统从异常抛出点所在的函数开始，沿着调用栈向上查找，寻找能够捕获该类型异常的 catch 块。查找的顺序是逆序的，即从当前函数调用栈帧 (stack frame) 向外层调用栈帧查找。
② 栈帧清理 (Stack Frame Cleanup)：对于每个被遍历到的栈帧，运行时系统会执行以下清理操作：
▮▮▮▮⚝ 局部对象析构 (Local Object Destruction)：在该栈帧中创建的所有局部对象 (包括自动存储期对象和临时对象) 的析构函数会被按照构造顺序的逆序依次调用。这是栈展开的核心步骤，确保了 RAII 对象能够正确释放资源。
▮▮▮▮⚝ 栈帧弹出 (Stack Frame Pop)：栈帧被从调用栈中弹出。
③ 继续向上查找 (Continue Searching Upwards)：如果当前栈帧没有找到合适的 catch 块，栈展开过程会继续向上一个调用栈帧重复步骤 ②。
④ 找到 catch 块或程序终止 (Catch Handler Found or Program Termination)：
▮▮▮▮⚝ 如果在某个栈帧中找到了能够捕获该类型异常的 catch 块，栈展开过程停止，程序控制权转移到该 catch 块，开始执行异常处理代码。
▮▮▮▮⚝ 如果一直向上遍历到 main() 函数的栈帧，仍然没有找到合适的 catch 块，那么异常被认为是未捕获异常 (uncaught exception)。默认情况下，C++ 运行时系统会调用 std::terminate 函数，导致程序异常终止。可以通过 std::set_terminate 函数自定义未捕获异常的处理方式。
局部对象析构顺序 (Destruction Order of Local Objects)：
在栈展开过程中，每个栈帧内的局部对象的析构函数会被调用。析构函数的调用顺序与对象的构造顺序相反。这是非常重要的，因为它保证了在资源管理方面，后构造的对象先析构，这通常是符合逻辑的，例如，如果对象 A 的构造依赖于对象 B，那么在析构时，应该先析构 A，再析构 B。
栈展开的性能影响 (Performance Impact of Stack Unwinding)：
栈展开是一个相对昂贵的操作，相比于正常的函数返回，它会带来额外的性能开销。主要的开销来自于：
① 栈帧遍历和清理 (Stack Frame Traversal and Cleanup)：运行时系统需要遍历调用栈，并对每个栈帧执行清理操作，包括局部对象析构和栈帧弹出。这需要一定的时间开销，尤其是在调用栈很深的情况下。
② 析构函数执行 (Destructor Execution)：每个局部对象的析构函数都需要被调用并执行。如果析构函数本身比较耗时 (例如，需要进行复杂的资源释放操作)，那么栈展开的开销会进一步增加。
③ 指令缓存和数据缓存失效 (Instruction Cache and Data Cache Misses)：栈展开过程可能会导致指令缓存和数据缓存失效，因为程序控制流会突然跳转到异常处理代码，而不是顺序执行。这也会对性能产生负面影响。
优化栈展开的性能 (Optimizing Stack Unwinding Performance)：
虽然栈展开有性能开销，但在很多情况下，为了程序的健壮性和异常安全，使用异常处理是值得的。可以采取一些措施来尽量减少栈展开的性能影响：
① 减少不必要的异常抛出 (Minimize Unnecessary Exception Throwing)：异常应该用于处理真正异常的情况，即程序无法正常继续执行的错误。对于可以预期的、正常的错误情况，应该使用错误码或其他错误处理机制，而不是异常。
② 避免在性能关键路径上频繁抛出异常 (Avoid Frequent Exception Throwing on Performance-Critical Paths)：如果程序的性能关键路径上经常抛出异常，可能会显著影响性能。应该尽量优化代码逻辑，减少异常发生的频率。
③ 合理使用 noexcept 说明符 (Use noexcept Specifier Judiciously)：对于确定不会抛出异常的函数，应该使用 noexcept 说明符进行声明。noexcept 可以帮助编译器进行优化，例如，在某些情况下，编译器可以避免生成栈展开的代码，从而提高性能。
④ 简化析构函数 (Simplify Destructors)：尽量使 RAII 对象的析构函数简单高效，避免在析构函数中执行耗时的操作。
示例代码 (栈展开过程演示)：
1
#include <iostream>
2
#include <stdexcept>
3
4
class Resource {
5
public:
6
Resource(const std::string& name) : name_(name) {
7
std::cout << "Resource '" << name_ << "' acquired." << std::endl;
8
}
9
~Resource() {
10
std::cout << "Resource '" << name_ << "' released." << std::endl;
11
}
12
private:
13
std::string name_;
14
};
15
16
void func_c() {
17
Resource res_c("Resource C");
18
std::cout << "func_c: before throw" << std::endl;
19
throw std::runtime_error("Exception in func_c"); // 抛出异常
20
std::cout << "func_c: after throw (never reached)" << std::endl;
21
}
22
23
void func_b() {
24
Resource res_b("Resource B");
25
std::cout << "func_b: calling func_c" << std::endl;
26
func_c();
27
std::cout << "func_b: after func_c call (never reached)" << std::endl;
28
}
29
30
void func_a() {
31
Resource res_a("Resource A");
32
std::cout << "func_a: calling func_b" << std::endl;
33
try {
34
func_b();
35
} catch (const std::runtime_error& e) {
36
std::cerr << "Caught exception in func_a: " << e.what() << std::endl;
37
}
38
std::cout << "func_a: after func_b call" << std::endl;
39
}
40
41
int main() {
42
std::cout << "main: calling func_a" << std::endl;
43
func_a();
44
std::cout << "main: after func_a call" << std::endl;
45
return 0;
46
}
输出结果 (示例)：
1
main: calling func_a
2
func_a: calling func_b
3
Resource 'Resource A' acquired.
4
func_b: calling func_c
5
Resource 'Resource B' acquired.
6
func_c: before throw
7
Resource 'Resource C' acquired.
8
Resource 'Resource C' released.
9
Resource 'Resource B' released.
10
Caught exception in func_a: Exception in func_c
11
Resource 'Resource A' released.
12
func_a: after func_b call
13
main: after func_a call
分析输出结果：
⚝ 当 func_c 抛出异常时，func_c 中局部对象 res_c 的析构函数首先被调用 (Resource 'Resource C' released.)。
⚝ 然后栈展开到 func_b，func_b 中局部对象 res_b 的析构函数被调用 (Resource 'Resource B' released.)。
⚝ 栈继续展开到 func_a，func_a 中的 try-catch 块捕获了异常。在 catch 块执行之前，func_a 中局部对象 res_a 的析构函数 没有被调用。只有当 func_a 函数执行完毕，res_a 的析构函数才会被调用 (Resource 'Resource A' released.)。
⚝ 局部对象的析构顺序是构造顺序的逆序 (C, B, A)。
⚝ func_c 和 func_b 中 throw 语句之后的代码不会被执行，程序控制流直接跳转到 func_a 的 catch 块。
总结栈展开：
栈展开是 C++ 异常处理机制的关键组成部分。它确保了在异常传播过程中，调用栈上的局部对象能够被正确析构，从而实现了资源的自动管理和异常安全。理解栈展开的过程、局部对象析构顺序和性能影响，有助于编写更有效、更可靠的异常处理代码。虽然栈展开有性能开销，但通过合理的异常使用和代码优化，可以将其影响降到最低。
4.3.3 异常的传播与未捕获异常 (Exception Propagation and Uncaught Exceptions)
说明异常如何在调用栈中传播，直到被 catch 块捕获，以及未捕获异常的处理方式 (通常会导致程序终止)。
异常的传播 (Exception Propagation)：
当一个异常在某个函数中被 throw 抛出时，如果当前函数没有 try-catch 块能够捕获这个异常，异常就会沿着调用栈向上传播。这个传播过程就是异常传播 (exception propagation)。
① 向上查找 catch 块 (Searching Up the Call Stack)：异常从抛出点开始，沿着调用栈逆序向上查找。运行时系统会检查调用栈中每一层函数的 try-catch 块，看是否有能够捕获该类型异常的 catch 子句。
② 栈展开 (Stack Unwinding)：在异常传播过程中，会发生栈展开 (stack unwinding)。对于每个被遍历到的栈帧，局部对象的析构函数会被按照构造顺序的逆序调用，然后栈帧被弹出。栈展开的详细过程见 4.3.2 节。
③ 传播到调用者 (Propagation to the Caller)：如果当前函数没有找到合适的 catch 块，异常会继续传播到调用当前函数的函数 (即，调用栈的上一层)。这个过程会不断重复，直到找到能够捕获该异常的 catch 块，或者传播到 main() 函数。
④ 捕获与处理 (Catching and Handling)：如果在某个函数中找到了能够捕获该类型异常的 catch 块，异常传播停止，程序控制权转移到该 catch 块，开始执行异常处理代码。catch 块会根据异常类型进行相应的处理，例如，记录日志、资源清理、用户提示、重试操作等。
⑤ 重新抛出 (Re-throwing)：在 catch 块中，可以使用 throw; (不带任何操作数) 语句重新抛出 (re-throw) 当前捕获的异常。重新抛出会导致异常继续沿着调用栈向上传播，寻找更外层的 catch 块来处理。重新抛出通常用于在当前的 catch 块中只做一些局部处理 (例如，记录日志)，然后将异常传递给更上层的代码进行更全面的处理。
未捕获异常 (Uncaught Exceptions)：
如果异常一直传播到 main() 函数的栈帧，仍然没有找到能够捕获它的 catch 块，那么这个异常就被称为未捕获异常 (uncaught exception)。
① 默认处理：std::terminate (Default Handling: std::terminate)：对于未捕获异常，C++ 标准库的默认处理方式是调用 std::terminate 函数。std::terminate 函数会调用 std::abort 函数，导致程序立即异常终止 (abnormal termination)。程序会停止执行，不会进行任何清理操作 (除了可能由操作系统进行的资源回收)。
② 自定义处理：std::set_terminate 和 std::terminate_handler (Custom Handling: std::set_terminate and std::terminate_handler)：C++ 允许程序员自定义未捕获异常的处理方式。可以使用 std::set_terminate 函数设置一个终止处理函数 (terminate handler)。终止处理函数是一个无参数、无返回值的函数，类型为 std::terminate_handler。当发生未捕获异常时，运行时系统会调用通过 std::set_terminate 设置的自定义终止处理函数，而不是默认的 std::terminate。
③ 终止处理函数的限制 (Limitations of Terminate Handler)：终止处理函数的主要目的是在程序终止前执行一些最后的清理或日志记录工作。终止处理函数不能阻止程序终止，也不能尝试恢复程序执行。在终止处理函数中抛出异常是未定义行为 (undefined behavior)。终止处理函数应该尽量简单、可靠，避免执行可能导致错误或崩溃的操作。
示例代码 (异常传播与未捕获异常)：
1
#include <iostream>
2
#include <stdexcept>
3
#include <cstdlib> // std::abort
4
#include <exception> // std::set_terminate, std::terminate_handler
5
6
void func_d() {
7
std::cout << "func_d: before throw" << std::endl;
8
throw std::runtime_error("Exception in func_d"); // 抛出异常，但 func_d 没有 try-catch
9
std::cout << "func_d: after throw (never reached)" << std::endl;
10
}
11
12
void func_c() {
13
std::cout << "func_c: calling func_d" << std::endl;
14
func_d(); // func_c 也没有 try-catch，异常会继续传播
15
std::cout << "func_c: after func_d call (never reached)" << std::endl;
16
}
17
18
void func_b() {
19
std::cout << "func_b: calling func_c" << std::endl;
20
func_c(); // func_b 也没有 try-catch，异常继续传播
21
std::cout << "func_b: after func_c call (never reached)" << std::endl;
22
}
23
24
void func_a() {
25
std::cout << "func_a: calling func_b" << std::endl;
26
func_b(); // func_a 也没有 try-catch，异常继续传播
27
std::cout << "func_a: after func_b call (never reached)" << std::endl;
28
}
29
30
void my_terminate_handler() {
31
std::cerr << "Custom terminate handler called due to uncaught exception!" << std::endl;
32
std::abort(); // 仍然需要调用 std::abort 来终止程序，或者 std::exit
33
}
34
35
int main() {
36
std::set_terminate(my_terminate_handler); // 设置自定义终止处理函数
37
std::cout << "main: calling func_a" << std::endl;
38
try {
39
func_a(); // main 函数的 try-catch 块包裹 func_a 调用，但这里捕获不到 func_d 抛出的异常，因为类型不匹配
40
} catch (const std::logic_error& e) { // 只能捕获 std::logic_error 及其派生类异常
41
std::cerr << "Caught logic_error in main: " << e.what() << std::endl;
42
}
43
std::cout << "main: after func_a call (if exception is caught)" << std::endl; // 如果异常被 catch，会执行到这里，但本例中不会
44
return 0; // 如果异常被 catch，会执行到这里，但本例中不会
45
}
输出结果 (示例)：
1
main: calling func_a
2
func_a: calling func_b
3
func_b: calling func_c
4
func_c: calling func_d
5
func_d: before throw
6
Custom terminate handler called due to uncaught exception!
7
Aborted (core dumped)
分析输出结果：
⚝ func_d 抛出的 std::runtime_error 异常，由于 func_d, func_c, func_b, func_a 都没有 try-catch 块捕获 std::runtime_error 类型的异常，最终传播到了 main() 函数。
⚝ main() 函数的 try-catch 块只能捕获 std::logic_error 类型的异常，与 std::runtime_error 类型不匹配，因此异常没有被捕获。
⚝ 由于异常未被捕获，运行时系统调用了通过 std::set_terminate 设置的自定义终止处理函数 my_terminate_handler。
⚝ my_terminate_handler 函数输出了错误消息 "Custom terminate handler called due to uncaught exception!"，然后调用 std::abort() 终止了程序。
⚝ 程序异常终止，"main: after func_a call" 和 "main: after func_a call (if exception is caught)" 等后续代码没有被执行。
总结异常传播与未捕获异常：
异常会沿着调用栈向上传播，直到被合适的 catch 块捕获。栈展开在传播过程中清理资源。如果异常传播到 main() 函数仍然未被捕获，则成为未捕获异常，默认会导致程序终止。可以通过 std::set_terminate 自定义未捕获异常的处理方式，但自定义处理函数通常只能进行最后的清理和日志记录，无法阻止程序终止。理解异常传播机制和未捕获异常的处理方式，对于编写健壮的异常处理代码和避免程序意外终止非常重要。
5. RAII 与异常安全编程 (RAII and Exception-Safe Programming)
5.1 RAII 惯用法详解 (Detailed Explanation of RAII Idiom)
5.1.1 RAII 的概念和原理 (Concept and Principles of RAII)
RAII (Resource Acquisition Is Initialization)，即“资源获取即初始化”，是一种 C++ 中被广泛采用的编程惯用法 (idiom)。它的核心思想是将资源的生命周期与对象的生命周期绑定在一起。更具体地说，RAII 确保在对象构造时获取资源 (Resource Acquisition)，并在对象析构时释放资源 (is Initialization)。
这里的“资源”可以泛指任何需要在程序中使用和管理的实体，例如：
⚝ 内存 (Memory)：通过 new 分配的动态内存。
⚝ 文件句柄 (File Handle)：通过 fopen 或 open 打开的文件。
⚝ 互斥锁 (Mutex Lock)：用于多线程同步的锁。
⚝ 网络连接 (Network Connection)：建立的网络套接字连接。
⚝ 数据库连接 (Database Connection)：与数据库建立的连接。
⚝ GDI 对象 (GDI Object)：Windows 图形设备接口对象。
RAII 的原理基于 C++ 的一项核心语言特性：对象的析构函数 (destructor) 会在对象生命周期结束时被自动调用。无论对象是如何结束其生命周期的，包括正常离开作用域、被显式删除 (通过 delete)，或者由于异常 (exception) 导致栈展开 (stack unwinding)，析构函数都会被执行。
因此，通过将资源的获取放在对象的构造函数 (constructor) 中，并将资源的释放放在对象的析构函数中，RAII 能够确保资源在任何情况下都能被及时、正确地释放，从而有效地避免资源泄漏 (resource leak) 问题。
简而言之，RAII 的精髓可以概括为以下两点：
① 封装 (Encapsulation)：将资源的管理逻辑封装在类中，隐藏资源管理的细节，提供清晰简洁的接口。
② 自动化 (Automation)：利用 C++ 语言的自动析构机制，实现资源的自动释放，无需显式地手动释放资源。
RAII 的核心思想可以用以下伪代码来表示：
1
class ResourceWrapper {
2
private:
3
ResourceType* resource; // 资源句柄
4
5
public:
6
// 构造函数：获取资源
7
ResourceWrapper() {
8
resource = acquireResource(); // 获取资源，例如分配内存、打开文件等
9
if (resource == nullptr) {
10
// 资源获取失败，抛出异常或进行错误处理
11
throw std::runtime_error("Failed to acquire resource");
12
}
13
}
14
15
// 析构函数：释放资源
16
~ResourceWrapper() {
17
releaseResource(resource); // 释放资源，例如释放内存、关闭文件等
18
resource = nullptr;
19
}
20
21
// 提供访问资源的方法 (可选)
22
ResourceType* getResource() const {
23
return resource;
24
}
25
26
// 其他操作资源的方法 ...
27
};
28
29
void function() {
30
ResourceWrapper wrapper; // 创建 RAII 对象，资源在构造函数中被获取
31
// ... 使用资源 ...
32
33
} // 函数结束，wrapper 对象离开作用域，析构函数自动调用，资源被释放
在上述代码中，ResourceWrapper 类就是一个 RAII 类的示例。当在 function 函数中创建 wrapper 对象时，ResourceWrapper 的构造函数会被调用，并在构造函数中获取资源。当 function 函数结束时，wrapper 对象离开作用域，其析构函数会被自动调用，并在析构函数中释放资源。即使在 // ... 使用资源 ... 的代码段中发生异常，导致函数提前退出，wrapper 对象的析构函数仍然会被执行，从而保证资源被正确释放。
5.1.2 RAII 的优势：自动资源管理 (Advantages of RAII: Automatic Resource Management)
RAII 惯用法带来了诸多显著的优势，尤其是在资源管理和异常安全方面。以下是 RAII 的主要优势：
① 自动资源管理 (Automatic Resource Management)：RAII 最核心的优势在于实现了资源的自动管理。程序员不再需要显式地记住在何时何地释放资源，资源的释放完全由 RAII 对象的生命周期自动控制。这极大地简化了资源管理，降低了出错的可能性。
② 防止资源泄漏 (Preventing Resource Leaks)：由于资源的释放与对象的析构函数绑定，无论程序执行流程如何，只要 RAII 对象被销毁（例如，离开作用域、程序退出、异常栈展开等），析构函数就一定会被调用，从而保证资源得到释放。这有效地防止了各种原因导致的资源泄漏，例如忘记释放资源、在异常处理中遗漏资源释放等。
③ 提高代码的健壮性 (Improving Code Robustness)：RAII 使得资源管理更加可靠和可预测。即使在复杂的程序逻辑和异常处理流程中，资源也能得到妥善管理，从而提高了程序的健壮性和稳定性。程序不再容易因为资源泄漏而崩溃或出现异常行为。
④ 简化代码，提高可读性和可维护性 (Simplifying Code, Improving Readability and Maintainability)：使用 RAII 可以将资源管理的样板代码 (boilerplate code) 封装在 RAII 类中，使得业务逻辑代码更加简洁清晰。程序员可以专注于核心业务逻辑，而无需过多关注底层的资源管理细节。这提高了代码的可读性和可维护性。
⑤ 与异常处理机制良好配合 (Working Well with Exception Handling)：RAII 与 C++ 的异常处理机制完美配合。当异常发生时，栈展开 (stack unwinding) 机制会确保所有栈上的对象按照构造顺序的逆序被析构。这意味着，如果资源是通过 RAII 对象管理的，那么即使在异常情况下，资源的析构函数也会被调用，从而保证资源被正确释放。这使得编写异常安全的代码变得更加容易。
⑥ 适用于多种资源类型 (Applicable to Various Resource Types)：RAII 惯用法不局限于特定的资源类型，可以应用于各种需要管理的资源，例如内存、文件句柄、锁、网络连接、数据库连接等。这使得 RAII 成为一种通用的资源管理技术。
⑦ 提高开发效率 (Improving Development Efficiency)：由于 RAII 简化了资源管理，减少了手动管理资源的复杂性和出错概率，程序员可以将更多精力投入到业务逻辑的开发中，从而提高开发效率。
总而言之，RAII 是一种强大而有效的资源管理技术，它通过将资源管理与对象的生命周期绑定，实现了资源的自动、安全、可靠的管理。在现代 C++ 编程中，RAII 已经成为编写高质量、健壮、异常安全代码的基石。
5.1.3 实现 RAII 的关键：构造函数和析构函数 (Key to RAII: Constructors and Destructors)
实现 RAII 惯用法的关键在于构造函数 (constructor) 和 析构函数 (destructor) 的设计。正如 RAII 的名称所示，“资源获取即初始化”，构造函数负责资源的获取 (Resource Acquisition)，而析构函数负责资源的释放 (Initialization)。
① 构造函数 (Constructor)：
⚝ 资源获取 (Acquire Resource)：构造函数的主要职责是在对象创建时获取所需的资源。这可能包括：
▮▮▮▮⚝ 分配内存：使用 new 或其他内存分配器分配内存。
▮▮▮▮⚝ 打开文件：使用 fopen、open 或文件流对象打开文件。
▮▮▮▮⚝ 获取锁：使用互斥锁对象的 lock() 方法获取锁。
▮▮▮▮⚝ 建立网络连接：创建套接字并连接到服务器。
▮▮▮▮⚝ 分配其他系统资源：例如，GDI 对象、数据库连接等。
⚝ 初始化状态 (Initialize State)：构造函数还应该初始化对象的内部状态，使其处于可用状态。这包括设置成员变量的初始值，建立对象之间的关联关系等。
⚝ 错误处理 (Error Handling)：在资源获取过程中，可能会发生错误，例如内存分配失败、文件打开失败、连接超时等。构造函数必须妥善处理这些错误。常见的错误处理方式包括：
▮▮▮▮⚝ 抛出异常 (Throw Exception)：如果资源获取失败，构造函数应该抛出一个异常，例如 std::bad_alloc (内存分配失败)、std::runtime_error (其他运行时错误) 或自定义异常。抛出异常可以立即终止对象的构造过程，并向上层调用者报告错误。这是 RAII 中推荐的错误处理方式，因为它能够确保对象在资源获取失败时不会被创建出来，从而避免后续的资源管理问题。
▮▮▮▮⚝ 设置错误标志 (Set Error Flag)：在某些情况下，可能不希望在构造函数中抛出异常（例如，在某些性能敏感的场景）。此时，可以考虑在对象内部设置一个错误标志，并在后续的操作中检查该标志，以判断对象是否成功初始化。但是，这种方式不如抛出异常清晰和安全，需要谨慎使用。
⚝ 不可重入性 (Non-Reentrancy)：构造函数通常应该是不可重入的 (non-reentrant)，即在构造函数执行过程中，不应该再次调用同一个构造函数来创建新的对象。如果需要支持对象的复制或移动，应该通过拷贝构造函数 (copy constructor) 和移动构造函数 (move constructor) 来实现。
② 析构函数 (Destructor)：
⚝ 资源释放 (Release Resource)：析构函数的主要职责是在对象销毁时释放构造函数中获取的资源。这与构造函数中的资源获取操作相对应，例如：
▮▮▮▮⚝ 释放内存：使用 delete 或其他内存释放器释放内存。
▮▮▮▮⚝ 关闭文件：使用 fclose、close 或文件流对象的析构函数关闭文件。
▮▮▮▮⚝ 释放锁：使用互斥锁对象的 unlock() 方法释放锁。
▮▮▮▮⚝ 关闭网络连接：关闭套接字连接。
▮▮▮▮⚝ 释放其他系统资源：例如，释放 GDI 对象、关闭数据库连接等。
⚝ 清理状态 (Clean Up State)：析构函数还应该清理对象的内部状态，例如释放对象持有的其他资源、断开对象之间的关联关系等。
⚝ 不应抛出异常 (Should Not Throw Exception)：析构函数绝对不应该抛出异常。这是 C++ 异常处理机制的一个重要约束。如果在栈展开 (stack unwinding) 过程中，析构函数抛出异常，会导致程序立即终止 (调用 std::terminate)。因此，在析构函数中，必须确保所有的资源释放操作都不会抛出异常。如果资源释放操作有可能失败，应该在析构函数内部捕获并处理这些错误，例如记录错误日志、进行重试等，但绝对不能让异常逃逸出析构函数。
⚝ 可重入性 (Reentrancy)：析构函数通常应该是可重入的 (reentrant)，即可以安全地被多次调用。虽然正常情况下析构函数只会被调用一次，但在某些特殊情况下（例如，使用 placement new 手动管理对象生命周期），析构函数可能会被多次调用。因此，析构函数应该能够处理这种情况，避免重复释放资源或导致其他错误。
总结：构造函数负责资源的获取和对象的初始化，析构函数负责资源的释放和对象的清理。构造函数应该在资源获取失败时抛出异常，而析构函数则绝对不应该抛出异常。构造函数和析构函数的正确设计是实现 RAII 惯用法的关键。
5.1.4 RAII 的应用示例 (Examples of RAII Applications)
RAII 惯用法在 C++ 编程中有着广泛的应用，几乎所有需要资源管理的地方都可以使用 RAII 来简化代码、提高可靠性。以下是一些常见的 RAII 应用示例：
① 内存管理：智能指针 (Smart Pointers for Memory Management)
智能指针 (smart pointer) 是 RAII 最经典的应用之一。C++ 标准库提供了多种智能指针类型，例如 std::unique_ptr, std::shared_ptr, std::weak_ptr 等，它们都遵循 RAII 原则，用于自动管理动态分配的内存。
⚝ std::unique_ptr: 用于独占式资源管理，确保只有一个 unique_ptr 指针指向特定的内存资源。当 unique_ptr 对象销毁时，它所管理的内存会被自动释放。
1
#include <memory>
2
#include <iostream>
3
4
void example_unique_ptr() {
5
std::unique_ptr<int> ptr(new int(10)); // 使用 unique_ptr 管理动态分配的 int
6
std::cout << *ptr << std::endl; // 访问资源
7
8
} // ptr 离开作用域，析构函数自动释放内存
⚝ std::shared_ptr: 用于共享式资源管理，允许多个 shared_ptr 指针共享同一个内存资源。当最后一个指向该资源的 shared_ptr 对象销毁时，内存才会被释放。
1
#include <memory>
2
#include <iostream>
3
4
void example_shared_ptr() {
5
std::shared_ptr<int> ptr1(new int(20));
6
std::shared_ptr<int> ptr2 = ptr1; // 多个 shared_ptr 共享资源
7
std::cout << *ptr1 << ", " << *ptr2 << std::endl;
8
9
} // ptr1 和 ptr2 离开作用域，最后一个 shared_ptr 析构时释放内存
② 文件操作 (File Operations)
文件操作通常需要打开文件、进行读写操作，并在操作完成后关闭文件。如果手动管理文件句柄，很容易忘记关闭文件或在异常情况下未能关闭文件，导致资源泄漏。使用 RAII 可以将文件句柄封装在类中，确保文件在对象销毁时被自动关闭。
1
#include <fstream>
2
#include <iostream>
3
#include <stdexcept>
4
5
class FileGuard {
6
private:
7
std::ofstream file;
8
std::string filename;
9
10
public:
11
FileGuard(const std::string& fname) : filename(fname), file(fname) {
12
if (!file.is_open()) {
13
throw std::runtime_error("Failed to open file: " + filename);
14
}
15
}
16
17
~FileGuard() {
18
if (file.is_open()) {
19
file.close();
20
std::cout << "File '" << filename << "' closed." << std::endl;
21
}
22
}
23
24
std::ofstream& getFileStream() {
25
return file;
26
}
27
};
28
29
void example_file_raii() {
30
try {
31
FileGuard guard("output.txt"); // 创建 FileGuard 对象，文件在构造函数中打开
32
guard.getFileStream() << "Hello, RAII FileGuard!" << std::endl;
33
// ... 文件操作 ...
34
35
} catch (const std::exception& e) {
36
std::cerr << "Exception: " << e.what() << std::endl;
37
}
38
39
} // guard 离开作用域，析构函数自动关闭文件
③ 互斥锁 (Mutex Locks)
在多线程编程中，互斥锁用于保护共享资源，避免数据竞争。使用 RAII 可以将互斥锁的加锁和解锁操作封装在类中，确保锁在任何情况下都能被正确释放，即使在临界区 (critical section) 中发生异常。
1
#include <mutex>
2
#include <iostream>
3
4
class LockGuard {
5
private:
6
std::mutex& mutex;
7
8
public:
9
LockGuard(std::mutex& m) : mutex(m) {
10
mutex.lock(); // 构造函数中加锁
11
std::cout << "Mutex locked." << std::endl;
12
}
13
14
~LockGuard() {
15
mutex.unlock(); // 析构函数中解锁
16
std::cout << "Mutex unlocked." << std::endl;
17
}
18
};
19
20
std::mutex global_mutex;
21
22
void example_mutex_raii() {
23
LockGuard lock(global_mutex); // 创建 LockGuard 对象，构造函数自动加锁
24
// ... 临界区代码，访问共享资源 ...
25
std::cout << "Inside critical section." << std::endl;
26
27
} // lock 离开作用域，析构函数自动解锁
④ 自定义资源管理类 (Custom Resource Management Classes)
RAII 也可以用于管理自定义的资源，例如数据库连接、网络套接字、GDI 对象等。只需要根据资源的特性，设计相应的 RAII 类，将资源的获取和释放逻辑封装在构造函数和析构函数中即可。
总之，RAII 是一种通用的资源管理技术，可以应用于各种需要资源管理的场景。通过合理地运用 RAII，可以编写出更加简洁、健壮、异常安全的 C++ 代码。
5.2 异常安全级别 (Exception Safety Levels)
在异常处理编程中，异常安全 (exception safety) 是一个至关重要的概念。它描述了当异常发生时，代码能够提供的保证程度。根据不同的保证程度，异常安全可以分为不同的级别。理解这些级别对于编写可靠的、能够优雅地处理异常的 C++ 代码至关重要。
通常，异常安全可以分为以下四个级别，从低到高依次增强保证：
① 不提供保证 (No Guarantee)
② 基本保证 (Basic Guarantee)
③ 强异常安全保证 (Strong Exception Safety Guarantee)
④ 无异常保证 (No-throw Guarantee)
5.2.1 不提供保证 (No Guarantee)
不提供保证 (No Guarantee)，也称为最弱异常安全级别，意味着当异常发生时，代码不提供任何保证。处于这种级别的代码，在异常发生后，可能会出现以下情况：
⚝ 程序状态不确定 (Indeterminate Program State)：程序的状态可能变得不一致或损坏，无法预测程序的后续行为。例如，对象可能处于无效状态，数据结构可能被破坏，程序逻辑可能出现混乱。
⚝ 资源泄漏 (Resource Leaks)：可能发生资源泄漏，例如内存泄漏、文件句柄泄漏、锁泄漏等。这是因为在异常发生时，可能有一些资源尚未被释放，而异常处理流程又未能正确地清理这些资源。
⚝ 程序崩溃 (Program Crash)：在最坏的情况下，程序可能会因为状态不一致或资源耗尽而崩溃。
示例：
1
#include <iostream>
2
#include <stdexcept>
3
4
void no_guarantee_function() {
5
int* ptr = new int[10]; // 分配内存
6
try {
7
// ... 一些可能抛出异常的操作 ...
8
if (true) {
9
throw std::runtime_error("Something went wrong!");
10
}
11
// ... 后续操作 ... (如果异常不抛出，会执行到这里)
12
delete[] ptr; // 释放内存
13
} catch (...) {
14
// ... 捕获异常，但没有处理资源释放 ...
15
// 此时，如果异常在 delete[] ptr 之前抛出，内存 ptr 将会泄漏
16
std::cerr << "Exception caught, but memory might leak!" << std::endl;
17
// ...
18
}
19
// 在 catch 块之外，ptr 指针仍然存在，但可能已经发生了内存泄漏
20
}
21
22
void test_no_guarantee() {
23
try {
24
no_guarantee_function();
25
} catch (const std::exception& e) {
26
std::cerr << "Test function caught exception: " << e.what() << std::endl;
27
}
28
}
在上述 no_guarantee_function 函数中，如果 throw std::runtime_error 语句被执行，异常会被抛出，程序会跳转到 catch 块。然而，由于 catch 块中没有释放之前分配的内存 ptr，因此会发生内存泄漏。此外，程序的状态也可能因为异常而变得不确定。
总结：不提供保证的代码是最不安全的异常安全级别。应该尽量避免编写不提供保证的代码，尤其是在资源管理和关键业务逻辑中。
5.2.2 基本保证 (Basic Guarantee)
基本保证 (Basic Guarantee)，也称为最小异常安全级别，承诺当异常发生时，代码至少能够保证以下两点：
① 程序不会崩溃 (No Program Crash)：程序不会因为异常而直接崩溃，能够继续运行下去，尽管可能处于某种错误状态。
② 没有资源泄漏 (No Resource Leaks)：所有已分配的资源（例如内存、文件句柄、锁等）都会被正确释放，即使在异常发生的情况下。
但基本保证不承诺程序的状态保持不变。在异常发生后，程序的状态可能会被修改，对象可能处于有效但未定义的状态，数据结构可能部分被修改。程序可能无法继续执行原来的业务逻辑，但至少不会崩溃，也不会发生资源泄漏。
示例：
1
#include <iostream>
2
#include <stdexcept>
3
#include <memory> // 引入智能指针
4
5
class ResourceUser {
6
private:
7
std::unique_ptr<int[]> data; // 使用 unique_ptr 管理内存
8
size_t size;
9
10
public:
11
ResourceUser(size_t s) : size(s), data(new int[s]) {
12
std::cout << "ResourceUser constructed, size = " << size << std::endl;
13
}
14
15
~ResourceUser() {
16
std::cout << "ResourceUser destructed, size = " << size << std::endl;
17
}
18
19
void operate() {
20
try {
21
// ... 一些可能抛出异常的操作 ...
22
if (true) {
23
throw std::runtime_error("Operation failed!");
24
}
25
// ... 后续操作 ... (如果异常不抛出，会执行到这里)
26
for (size_t i = 0; i < size; ++i) {
27
data[i] = i; // 修改对象状态
28
}
29
} catch (...) {
30
// ... 捕获异常，但不重新抛出 ...
31
std::cerr << "Exception caught in operate(), but resource is safe." << std::endl;
32
// 在异常发生时，data 智能指针会自动释放内存，保证没有资源泄漏
33
// 但对象的状态可能已经被部分修改，处于不确定状态
34
}
35
}
36
};
37
38
void test_basic_guarantee() {
39
ResourceUser user(5);
40
user.operate(); // 调用可能抛出异常的操作
41
42
} // user 对象离开作用域，析构函数自动释放内存
在上述 ResourceUser 类中，使用了 std::unique_ptr 来管理动态内存 data。即使在 operate() 函数中抛出异常，由于 data 是由 unique_ptr 管理的，当 user 对象析构时，data 所指向的内存仍然会被自动释放，从而保证没有内存泄漏。程序也不会崩溃（因为异常被 catch 块捕获）。但是，如果异常在 for 循环之前抛出，data 中的数据可能没有被完全初始化或修改，对象的状态可能处于不确定状态。
总结：基本保证是比不提供保证更高级别的异常安全级别。它通过 RAII 等技术，确保在异常情况下程序不会崩溃，并且没有资源泄漏。但是，程序的状态可能会被改变，可能需要进行额外的错误处理或恢复操作。
5.2.3 强异常安全保证 (Strong Exception Safety Guarantee)
强异常安全保证 (Strong Exception Safety Guarantee)，也称为事务性保证 (Transactional Guarantee) 或 commit-or-rollback 保证，是更高级别的异常安全级别。它承诺当操作抛出异常时，具有强异常安全保证的代码能够保证以下几点：
① 基本保证的所有承诺：即程序不会崩溃，没有资源泄漏。
② 操作要么完全成功，要么完全不生效 (Commit-or-Rollback)：如果操作成功完成，则程序状态会按照预期被修改。如果操作因为异常而失败，则程序状态会回滚到操作开始之前的状态，仿佛操作从未发生过一样。也就是说，操作具有“原子性 (atomicity)”：要么全部完成，要么全部不完成。
③ 程序状态保持不变 (Program State Unchanged)：在异常发生后，程序的状态（包括对象的状态、数据结构的状态等）会保持在操作开始之前的状态。对象不会被部分修改，数据结构不会被破坏，程序逻辑不会出现混乱。
强异常安全保证通常通过 “先做副本，再修改副本，最后提交副本 (copy-and-swap)” 或 “回滚 (rollback)” 等策略来实现。
示例：
1
#include <iostream>
2
#include <stdexcept>
3
#include <vector>
4
#include <algorithm>
5
6
class DataProcessor {
7
private:
8
std::vector<int> data;
9
10
public:
11
DataProcessor(std::vector<int> initialData) : data(initialData) {
12
std::cout << "DataProcessor constructed with initial data." << std::endl;
13
}
14
15
~DataProcessor() {
16
std::cout << "DataProcessor destructed." << std::endl;
17
}
18
19
void processData(int valueToAdd) {
20
std::vector<int> originalData = data; // 复制原始数据 (副本)
21
try {
22
std::vector<int> tempData = data; // 在副本上操作
23
// ... 一些可能抛出异常的操作 ...
24
if (true) {
25
throw std::runtime_error("Data processing failed!");
26
}
27
// ... 后续操作 ... (如果异常不抛出，会执行到这里)
28
tempData.push_back(valueToAdd); // 修改副本数据
29
std::sort(tempData.begin(), tempData.end()); // 修改副本数据
30
data = tempData; // 提交副本 (swap)
31
std::cout << "Data processing succeeded." << std::endl;
32
} catch (...) {
33
// ... 捕获异常，回滚操作 ...
34
data = originalData; // 恢复到原始数据 (回滚)
35
std::cerr << "Exception caught in processData(), data rolled back." << std::endl;
36
// 异常发生时，数据被回滚到操作前的状态，保证强异常安全
37
}
38
}
39
40
void printData() const {
41
std::cout << "Current data: ";
42
for (int val : data) {
43
std::cout << val << " ";
44
}
45
std::cout << std::endl;
46
}
47
};
48
49
void test_strong_guarantee() {
50
DataProcessor processor({1, 3, 2});
51
processor.printData(); // 初始数据
52
try {
53
processor.processData(4); // 调用可能抛出异常的操作
54
processor.printData(); // 操作后的数据 (如果成功)
55
} catch (const std::exception& e) {
56
std::cerr << "Test function caught exception: " << e.what() << std::endl;
57
processor.printData(); // 操作失败后的数据 (应回滚到初始状态)
58
}
59
}
在上述 DataProcessor 类中，processData() 函数实现了强异常安全保证。在操作开始前，先复制了原始数据 originalData。在 try 块中，所有操作都在副本 tempData 上进行。只有当所有操作都成功完成后，才将副本数据 tempData 赋值给原始数据 data（通过赋值或交换）。如果在操作过程中抛出异常，catch 块会将原始数据 originalData 赋值回 data，从而实现了数据回滚，保证了强异常安全。
总结：强异常安全保证是最高级别的异常安全级别之一。它提供了最强的承诺：操作要么成功完成，要么完全不生效，程序状态保持不变。强异常安全保证对于需要事务性操作或对数据一致性要求极高的场景非常重要。
5.2.4 无异常保证 (No-throw Guarantee)
无异常保证 (No-throw Guarantee)，也称为绝对异常安全保证 (Absolute Exception Safety Guarantee)，是最高级别的异常安全级别。它承诺代码绝对不会抛出任何异常。具有无异常保证的操作，在任何情况下都不会抛出异常，即使在资源不足、参数错误等异常情况下。
具有无异常保证的操作通常是非常基本、原子性的操作，例如：
⚝ 内存释放 (Memory Deallocation)：delete 运算符、智能指针的析构函数等。
⚝ 移动操作 (Move Operations)：移动构造函数、移动赋值运算符等（在满足特定条件时，例如被移动的对象处于有效但未定义状态）。
⚝ 析构函数 (Destructors)：C++ 规定析构函数不应抛出异常。
⚝ 交换 (Swap)：std::swap 函数（通常要求交换操作本身不会失败）。
使用 noexcept 说明符可以声明一个函数具有无异常保证。例如：
1
void no_throw_function() noexcept {
2
// ... 不会抛出异常的操作 ...
3
std::cout << "This function is noexcept." << std::endl;
4
}
示例：
1
#include <iostream>
2
#include <utility> // std::swap
3
4
class SafeInteger {
5
private:
6
int value;
7
8
public:
9
SafeInteger(int val = 0) noexcept : value(val) {} // 构造函数 noexcept
10
11
SafeInteger(SafeInteger&& other) noexcept : value(other.value) { // 移动构造函数 noexcept
12
other.value = 0; // 将源对象置于有效但未定义状态
13
}
14
15
SafeInteger& operator=(SafeInteger&& other) noexcept { // 移动赋值运算符 noexcept
16
if (this != &other) {
17
value = other.value;
18
other.value = 0;
19
}
20
return *this;
21
}
22
23
~SafeInteger() noexcept { // 析构函数 noexcept
24
// ... 资源释放操作 (此处没有资源需要释放，int 类型是值类型) ...
25
std::cout << "SafeInteger destructed." << std::endl;
26
}
27
28
void swap(SafeInteger& other) noexcept { // swap 函数 noexcept
29
std::swap(value, other.value);
30
}
31
32
int getValue() const noexcept { return value; }
33
};
34
35
void test_no_throw_guarantee() {
36
SafeInteger a(10);
37
SafeInteger b(20);
38
std::cout << "Before swap: a = " << a.getValue() << ", b = " << b.getValue() << std::endl;
39
a.swap(b); // 调用 noexcept swap 函数
40
std::cout << "After swap: a = " << a.getValue() << ", b = " << b.getValue() << std::endl;
41
42
SafeInteger c = std::move(a); // 调用 noexcept 移动构造函数
43
std::cout << "After move: c = " << c.getValue() << ", a = " << a.getValue() << std::endl;
44
45
} // a, b, c 对象离开作用域，析构函数自动调用 (noexcept)
在上述 SafeInteger 类中，构造函数、移动构造函数、移动赋值运算符、析构函数和 swap 函数都被声明为 noexcept，表示它们保证不会抛出异常。这些操作都是非常基本且原子性的，通常不会失败。
总结：无异常保证是最高级别的异常安全级别。它承诺操作绝对不会抛出异常。具有无异常保证的操作通常是程序中最基本、最底层的操作。noexcept 说明符用于声明函数具有无异常保证。
异常安全级别总结：
| 异常安全级别 | 保证内容 | 适用场景 | 实现难度 | 性能开销 |
|---|---|---|---|---|
| 不提供保证 (No Guarantee) | 无任何保证，程序状态可能不确定，可能资源泄漏，可能崩溃。 | 应当避免使用。 | 最低 | 最低 |
| 基本保证 (Basic Guarantee) | 程序不会崩溃，没有资源泄漏，但程序状态可能改变。 | 大多数情况下，基本保证是最低要求。对于不太关键的操作，基本保证可能就足够了。 | 较低 | 较低 |
| 强异常安全保证 (Strong Exception Safety Guarantee) | 操作要么成功完成，要么完全不生效，程序状态保持不变 (commit-or-rollback)。 | 对于关键操作、事务性操作、需要保证数据一致性的操作，强异常安全保证非常重要。例如，银行转账、数据库事务等。 | 较高 | 较高 |
| 无异常保证 (No-throw Guarantee) | 操作绝对不会抛出异常。 | 对于非常基本、原子性的操作，例如内存释放、移动操作、析构函数、交换等。标准库中的许多容器和算法都依赖于无异常保证的移动操作和交换操作来实现性能优化和强异常安全。 | 最高 | 几乎没有 |
选择合适的异常安全级别取决于具体的应用场景和需求。一般来说，基本保证是最低要求，应该尽量确保代码至少满足基本保证。对于关键业务逻辑和需要事务性操作的场景，应该努力实现强异常安全保证。对于最基本的操作，可以考虑提供无异常保证，以提高性能和可靠性。
5.3 编写异常安全代码的实践 (Practices for Writing Exception-Safe Code)
编写异常安全的代码需要遵循一些最佳实践和设计原则，以确保程序在异常情况下仍然能够保持稳定、可靠，并且不会发生资源泄漏。以下是一些编写异常安全代码的实用技巧和建议：
5.3.1 使用 RAII 管理所有资源 (Using RAII to Manage All Resources)
使用 RAII (Resource Acquisition Is Initialization) 惯用法是编写异常安全代码的基础和核心。正如前面章节所详细介绍的，RAII 通过将资源的生命周期与对象的生命周期绑定，实现了资源的自动管理，有效地避免了资源泄漏。
实践建议：
① 将所有需要管理的资源都封装在 RAII 类中：无论是内存、文件句柄、锁、网络连接，还是其他自定义资源，都应该使用 RAII 类进行封装和管理。不要使用裸指针 (raw pointer) 或手动管理资源，除非有非常特殊的原因和充分的理由。
② 优先使用标准库提供的 RAII 类：C++ 标准库已经提供了许多优秀的 RAII 类，例如智能指针 (std::unique_ptr, std::shared_ptr, std::weak_ptr)、文件流对象 (std::fstream, std::ofstream, std::ifstream)、互斥锁包装器 (std::lock_guard, std::unique_lock) 等。优先使用这些标准库提供的 RAII 类，可以减少代码量，提高代码质量和可移植性。
③ 自定义 RAII 类时，确保构造函数获取资源，析构函数释放资源：如果需要管理自定义的资源，需要自行设计 RAII 类。在设计 RAII 类时，务必遵循 RAII 的原则：在构造函数中获取资源，并在析构函数中释放资源。构造函数应该处理资源获取失败的情况（通常通过抛出异常），析构函数绝对不应该抛出异常。
④ 避免手动管理资源释放：一旦使用了 RAII 类来管理资源，就应该避免在代码中显式地手动释放资源。资源的释放应该完全由 RAII 对象的析构函数自动完成。手动释放资源可能会破坏 RAII 的资源管理机制，导致资源泄漏或程序错误。
示例：使用 RAII 管理动态数组
1
#include <iostream>
2
#include <memory>
3
#include <stdexcept>
4
5
class DynamicArray {
6
private:
7
std::unique_ptr<int[]> data; // 使用 unique_ptr 管理动态数组
8
size_t size;
9
10
public:
11
DynamicArray(size_t s) : size(s), data(new int[s]) {
12
if (!data) {
13
throw std::bad_alloc(); // 内存分配失败，抛出异常
14
}
15
std::cout << "DynamicArray constructed, size = " << size << std::endl;
16
}
17
18
~DynamicArray() {
19
std::cout << "DynamicArray destructed, size = " << size << std::endl;
20
}
21
22
int& operator[](size_t index) {
23
if (index >= size) {
24
throw std::out_of_range("Index out of range");
25
}
26
return data[index];
27
}
28
29
size_t getSize() const { return size; }
30
};
31
32
void example_raii_dynamic_array() {
33
try {
34
DynamicArray arr(10); // 创建 DynamicArray 对象，内存在构造函数中分配
35
for (size_t i = 0; i < arr.getSize(); ++i) {
36
arr[i] = i * 2;
37
}
38
for (size_t i = 0; i < arr.getSize(); ++i) {
39
std::cout << arr[i] << " ";
40
}
41
std::cout << std::endl;
42
43
} catch (const std::exception& e) {
44
std::cerr << "Exception: " << e.what() << std::endl;
45
}
46
47
} // arr 离开作用域，析构函数自动释放内存
在上述 DynamicArray 类中，使用了 std::unique_ptr<int[]> 来管理动态分配的整型数组。内存分配和释放都由 unique_ptr 自动处理，确保了内存安全和异常安全。
5.3.2 避免在析构函数中抛出异常 (Avoiding Exceptions in Destructors)
析构函数 (destructor) 绝对不应该抛出异常。这是 C++ 异常处理机制的一个重要约束，也是编写异常安全代码的关键原则之一。
原因：
⚝ 栈展开 (Stack Unwinding) 问题：当异常发生时，C++ 会进行栈展开 (stack unwinding) 操作，即销毁栈上的所有局部对象，包括调用它们的析构函数。如果在栈展开过程中，某个析构函数抛出异常，程序会立即调用 std::terminate() 终止执行，而不是继续处理异常。这会导致程序异常终止，并且可能无法完成正常的错误处理和资源清理。
⚝ 资源泄漏风险：如果在析构函数中抛出异常，可能会导致后续的析构函数无法被执行，从而造成资源泄漏。例如，如果一个对象包含多个 RAII 成员，并且在第一个成员的析构函数中抛出异常，那么后续成员的析构函数可能不会被调用，导致这些成员所管理的资源泄漏。
实践建议：
① 确保析构函数中的所有操作都不会抛出异常：在编写析构函数时，要仔细检查其中的代码，确保所有的资源释放操作、状态清理操作等都不会抛出异常。对于可能抛出异常的操作，应该进行适当的错误处理，例如捕获异常、记录错误日志、进行重试等，但绝对不能让异常逃逸出析构函数。
② 使用 noexcept 说明符声明析构函数：C++11 引入了 noexcept 说明符，可以用于声明函数不会抛出异常。应该将析构函数声明为 noexcept，以明确表示析构函数不会抛出异常，并让编译器进行相应的优化。
③ 如果析构函数中可能发生错误，在析构函数内部处理错误：如果析构函数中的资源释放操作有可能失败（例如，关闭文件时可能发生 I/O 错误），应该在析构函数内部捕获并处理这些错误。常见的处理方式包括：
▮▮▮▮⚝ 忽略错误 (Ignore Error)：在某些情况下，可以简单地忽略析构函数中发生的错误，例如文件关闭失败可能不会对程序造成严重影响。
▮▮▮▮⚝ 记录错误日志 (Log Error)：将错误信息记录到日志文件中，以便后续分析和排查问题。
▮▮▮▮⚝ 进行重试 (Retry)：对于某些可恢复的错误，可以尝试进行重试操作。但需要注意避免无限重试，以免程序陷入死循环。
示例：在析构函数中处理文件关闭错误
1
#include <fstream>
2
#include <iostream>
3
4
class FileCloser {
5
private:
6
std::ofstream file;
7
std::string filename;
8
9
public:
10
FileCloser(const std::string& fname) : filename(fname), file(fname) {
11
if (!file.is_open()) {
12
// 构造函数可以抛出异常
13
throw std::runtime_error("Failed to open file: " + filename);
14
}
15
}
16
17
~FileCloser() noexcept { // 析构函数声明为 noexcept
18
if (file.is_open()) {
19
file.close();
20
if (file.fail()) {
21
// 文件关闭失败，记录错误日志，但不抛出异常
22
std::cerr << "Error closing file: " << filename << std::endl;
23
// 可以选择忽略错误，或者进行其他错误处理，但不能抛出异常
24
} else {
25
std::cout << "File '" << filename << "' closed successfully." << std::endl;
26
}
27
}
28
}
29
30
std::ofstream& getFileStream() {
31
return file;
32
}
33
};
34
35
void example_destructor_noexcept() {
36
try {
37
FileCloser closer("output_destructor.txt");
38
closer.getFileStream() << "Data written to file." << std::endl;
39
// ... 文件操作 ...
40
41
} catch (const std::exception& e) {
42
std::cerr << "Exception: " << e.what() << std::endl;
43
}
44
45
} // closer 离开作用域，析构函数自动调用 (noexcept)
在上述 FileCloser 类的析构函数中，文件关闭操作 file.close() 可能会失败。为了避免析构函数抛出异常，代码检查了 file.fail()，如果文件关闭失败，则将错误信息输出到 std::cerr，但没有抛出异常。
5.3.3 Copy-and-Swap 惯用法 (Copy-and-Swap Idiom)
Copy-and-Swap 惯用法 是一种用于实现强异常安全赋值运算符 (strong exception-safe assignment operator) 的常用技术。它利用了 C++ 的拷贝构造函数 (copy constructor)、析构函数 (destructor) 和 swap 函数，以简洁而优雅的方式实现强异常安全保证。
原理：
Copy-and-Swap 惯用法的核心思想是：在副本上进行修改，只有当所有修改都成功完成后，才将副本与原始对象进行交换 (swap)。如果修改过程中发生异常，原始对象的状态不会被改变，从而保证了强异常安全。
实现步骤：
① 编写一个 swap 函数：为类编写一个非抛出异常的 swap 成员函数，用于交换两个对象的所有资源。swap 函数应该具有无异常保证 (noexcept)，并且只交换基本类型成员和智能指针等资源句柄，而不会抛出异常。
② 实现拷贝构造函数：拷贝构造函数应该负责创建对象的副本，包括深拷贝所有资源。拷贝构造函数可能会抛出异常（例如，内存分配失败）。
③ 实现赋值运算符：赋值运算符的实现步骤如下：
▮▮▮▮⚝ 创建原始对象的副本：利用拷贝构造函数创建一个当前对象的副本。
▮▮▮▮⚝ 交换副本与当前对象：调用 swap 函数，将副本的内容与当前对象的内容进行交换。由于 swap 函数是 noexcept 的，交换操作不会抛出异常。
▮▮▮▮⚝ 返回当前对象的引用：返回 *this。
示例：使用 Copy-and-Swap 实现强异常安全赋值运算符
1
#include <iostream>
2
#include <vector>
3
#include <algorithm>
4
5
class SafeVector {
6
private:
7
std::vector<int> data;
8
9
public:
10
SafeVector() = default; // 默认构造函数
11
SafeVector(const std::vector<int>& vec) : data(vec) {} // 构造函数
12
13
SafeVector(const SafeVector& other) : data(other.data) { // 拷贝构造函数
14
std::cout << "SafeVector copy constructor called." << std::endl;
15
}
16
17
SafeVector(SafeVector&& other) noexcept = default; // 移动构造函数
18
19
SafeVector& operator=(const SafeVector& other) { // 赋值运算符 (Copy-and-Swap)
20
std::cout << "SafeVector copy assignment operator called." << std::endl;
21
SafeVector temp = other; // 1. 创建副本 (通过拷贝构造函数)
22
swap(temp); // 2. 交换副本与当前对象
23
return *this; // 3. 返回当前对象的引用
24
}
25
26
SafeVector& operator=(SafeVector&& other) noexcept = default; // 移动赋值运算符
27
28
~SafeVector() = default; // 析构函数
29
30
void swap(SafeVector& other) noexcept { // swap 函数 (noexcept)
31
std::cout << "SafeVector swap function called." << std::endl;
32
std::swap(data, other.data); // 交换内部 vector
33
}
34
35
void print() const {
36
std::cout << "Data: ";
37
for (int val : data) {
38
std::cout << val << " ";
39
}
40
std::cout << std::endl;
41
}
42
};
43
44
void example_copy_and_swap() {
45
SafeVector vec1({1, 2, 3});
46
SafeVector vec2({4, 5, 6});
47
48
std::cout << "Before assignment:" << std::endl;
49
vec1.print(); // Data: 1 2 3
50
vec2.print(); // Data: 4 5 6
51
52
std::cout << "Assignment vec1 = vec2:" << std::endl;
53
vec1 = vec2; // 调用赋值运算符 (Copy-and-Swap)
54
55
std::cout << "After assignment:" << std::endl;
56
vec1.print(); // Data: 4 5 6
57
vec2.print(); // Data: 4 5 6
58
}
在上述 SafeVector 类中，赋值运算符使用了 Copy-and-Swap 惯用法。首先，通过拷贝构造函数创建了 other 对象的副本 temp。然后，调用 swap 函数将 temp 的内容与当前对象 *this 的内容进行交换。由于 swap 函数是 noexcept 的，交换操作不会抛出异常。如果在拷贝构造函数创建副本的过程中抛出异常，赋值操作会提前终止，而原始对象 *this 的状态不会被改变，从而实现了强异常安全保证。
优点：
⚝ 强异常安全：Copy-and-Swap 惯用法能够提供强异常安全保证，确保在赋值操作失败时，原始对象的状态保持不变。
⚝ 代码简洁：实现赋值运算符的代码非常简洁，只需要几行代码即可完成。
⚝ 易于理解和维护：Copy-and-Swap 惯用法的逻辑清晰，易于理解和维护。
⚝ 代码重用：利用了拷贝构造函数、析构函数和 swap 函数的代码重用，减少了代码冗余。
缺点：
⚝ 性能开销：Copy-and-Swap 惯用法需要创建对象的副本，可能会带来一定的性能开销，尤其是在对象包含大量资源或拷贝操作非常耗时的情况下。
⚝ 可能不适用于所有场景：对于某些特殊类型的对象，Copy-and-Swap 惯用法可能不适用，例如，如果对象的状态非常复杂，或者拷贝操作非常困难或不可能实现。
适用场景：
Copy-and-Swap 惯用法适用于大多数需要实现强异常安全赋值运算符的类，尤其是在对象包含动态分配的资源或需要复杂状态管理的情况下。对于性能要求不是非常苛刻的场景，Copy-and-Swap 是一种非常有效且易于实现强异常安全赋值运算符的技术。
5.3.4 异常安全函数的设计原则 (Design Principles for Exception-Safe Functions)
设计异常安全的函数需要遵循一些通用的原则，以确保函数在各种情况下（包括异常情况）都能正确地执行，并提供适当的异常安全级别。以下是一些异常安全函数的设计原则：
① 尽早获取资源 (Acquire Resources Early)：在函数开始执行时，尽早获取函数需要的所有资源，例如内存、文件句柄、锁等。这样可以避免在函数执行过程中，由于资源获取失败而导致程序状态不一致或资源泄漏。
② 使用 RAII 管理资源 (Use RAII to Manage Resources)：如前所述，使用 RAII 惯用法是编写异常安全代码的基础。在函数中，应该使用 RAII 类来管理所有需要管理的资源，确保资源在任何情况下都能被正确释放。
③ 避免裸指针 (Avoid Raw Pointers)：尽量避免在函数中使用裸指针来管理动态内存。应该优先使用智能指针 (std::unique_ptr, std::shared_ptr) 等 RAII 类来管理内存，自动处理内存的分配和释放。
④ 避免资源泄漏 (Avoid Resource Leaks)：在函数的设计和实现中，要时刻注意资源泄漏的风险。确保在所有可能的执行路径（包括正常执行路径和异常处理路径）上，所有已获取的资源都能被正确释放。使用 RAII 可以有效地避免资源泄漏。
⑤ 提供适当的异常安全级别 (Provide Appropriate Exception Safety Level)：根据函数的功能和应用场景，选择合适的异常安全级别（不提供保证、基本保证、强异常安全保证、无异常保证）。对于关键操作和需要事务性保证的场景，应该努力实现强异常安全保证。对于基本操作，至少应该提供基本保证。对于某些非常底层的操作，可以提供无异常保证。
⑥ 函数接口应明确声明异常规范 (Function Interface Should Clearly Specify Exception Specification)：在函数声明中，应该明确声明函数的异常规范，即函数是否会抛出异常，以及可能抛出的异常类型。可以使用 noexcept 说明符声明函数不会抛出异常，或者使用动态异常规范 (dynamic exception specification)（在 C++11 中已废弃，不推荐使用）或文档说明函数可能抛出的异常类型。明确的异常规范可以帮助调用者更好地理解和使用函数，并进行相应的异常处理。
⑦ 在错误发生时，保持对象和程序状态的一致性 (Maintain Object and Program State Consistency on Error)：当函数执行过程中发生错误或异常时，应该尽量保持对象和程序状态的一致性。如果函数需要修改对象的状态，应该在操作失败时，将对象状态回滚到操作开始之前的状态，或者至少保证对象处于有效但未定义的状态。使用强异常安全保证可以实现状态回滚。
⑧ 尽早报告错误 (Report Errors Early)：在函数执行过程中，如果发现错误或异常情况，应该尽早报告错误，例如抛出异常或返回错误码。尽早报告错误可以避免错误扩散，并让调用者及时处理错误。
⑨ 测试异常处理代码 (Test Exception Handling Code)：编写异常安全的代码后，需要进行充分的测试，包括正常执行路径的测试和异常处理路径的测试。要模拟各种异常情况，例如内存分配失败、文件打开失败、网络连接中断等，验证异常处理代码是否能够正确地处理异常，并保证程序的异常安全性。
示例：设计一个异常安全的资源管理函数
1
#include <iostream>
2
#include <fstream>
3
#include <stdexcept>
4
#include <memory>
5
6
// 异常安全的文件读取函数
7
std::string read_file_safely(const std::string& filename) {
8
std::ifstream file(filename); // RAII: 文件流对象，自动管理文件句柄
9
if (!file.is_open()) {
10
throw std::runtime_error("Failed to open file: " + filename); // 尽早报告错误
11
}
12
13
std::string content;
14
std::string line;
15
while (std::getline(file, line)) {
16
content += line + "\n";
17
}
18
19
if (file.fail() && !file.eof()) {
20
throw std::runtime_error("Error reading file: " + filename); // 尽早报告错误
21
}
22
23
return content; // 正常返回文件内容
24
} // file 离开作用域，析构函数自动关闭文件
25
26
void example_exception_safe_function() {
27
try {
28
std::string file_content = read_file_safely("input.txt");
29
std::cout << "File content:\n" << file_content << std::endl;
30
31
} catch (const std::exception& e) {
32
std::cerr << "Exception: " << e.what() << std::endl;
33
}
34
}
在上述 read_file_safely 函数中，使用了 RAII (文件流对象 std::ifstream) 来管理文件句柄，确保文件在任何情况下都能被自动关闭。函数在开始时就打开文件，尽早获取资源。如果文件打开失败或读取失败，会立即抛出异常，尽早报告错误。函数接口没有声明 noexcept，表示可能会抛出异常。函数返回文件内容，如果成功执行，返回正常结果；如果发生异常，则向上层调用者抛出异常，由调用者进行处理。
遵循以上设计原则，可以编写出更加健壮、可靠、异常安全的 C++ 代码，提高程序的质量和可维护性。
6. 异常处理的最佳实践 (Best Practices for Exception Handling)
章节概要
本章深入探讨 C++ 异常处理的最佳实践 🚀，旨在为开发者提供一套全面的指导原则，以确保在各种场景下都能有效地运用异常处理机制。我们将细致地讨论何时应当选择异常，何时错误码更为合适，并分析异常处理对程序性能的潜在影响。此外，本章还将提供一系列关于代码风格的实用建议，力求帮助读者编写出更健壮、更易于维护的异常处理代码。通过遵循这些最佳实践，开发者可以充分发挥 C++ 异常处理的优势，同时规避常见的陷阱，提升软件质量和开发效率。
6.1 何时使用异常？何时使用错误码？ (When to Use Exceptions? When to Use Error Codes?)
章节概要
本节旨在深入比较和分析异常 (Exceptions) 和错误码 (Error Codes) 这两种主要的错误处理机制，帮助读者理解它们各自的优势与局限性。我们将探讨在不同的应用场景下，如何权衡选择异常或错误码，并提供明确的指导原则，以便开发者能够根据具体情况做出最优决策。正确选择错误处理机制是构建健壮且高效软件的关键步骤，本节将为此提供重要的理论基础和实践指导。
6.1.1 异常的适用场景 (Use Cases for Exceptions)
小节概要
本小节将详细阐述异常在 C++ 编程中的适用场景，并列举一系列典型用例，以帮助读者理解何时应当优先考虑使用异常处理机制。我们将深入探讨异常在处理非预期错误、构造函数错误、以及深层函数调用错误等方面的优势，并解释为何在这些情况下异常能够提供更清晰、更有效的错误处理方案。
① 程序逻辑无法处理的意外情况 🤯：
异常最适合用于处理那些在程序正常逻辑流程之外、无法预料且无法恢复的错误情况。这类错误通常表明程序或运行环境出现了严重问题，例如：
⚝ 资源耗尽 (Resource Exhaustion)：内存分配失败 (std::bad_alloc)、文件句柄耗尽等。这些情况通常表明系统资源不足，程序无法继续正常运行。
⚝ 外部系统故障 (External System Failure)：网络连接中断、数据库服务不可用、文件系统错误等。这些故障通常超出程序自身的控制范围，需要通过异常来通知上层调用者。
⚝ 逻辑不一致性 (Logical Inconsistency)：程序状态进入了不应达到的非法状态，例如使用了空指针、数组越界访问等。这类错误通常是程序内部逻辑错误导致的，表明代码存在缺陷。
在这些情况下，使用异常能够 立即中断 当前的执行流程，并将错误信息传递到调用栈的上层，由合适的异常处理代码进行集中处理。这有助于避免错误在程序中蔓延，提高程序的健壮性。
1
#include <iostream>
2
#include <fstream>
3
#include <stdexcept>
4
5
void readFile(const std::string& filename) {
6
std::ifstream file(filename);
7
if (!file.is_open()) {
8
// 文件打开失败，抛出异常
9
throw std::runtime_error("Failed to open file: " + filename);
10
}
11
std::string line;
12
while (std::getline(file, line)) {
13
std::cout << line << std::endl;
14
}
15
file.close();
16
}
17
18
int main() {
19
try {
20
readFile("non_existent_file.txt"); // 可能会抛出异常
21
} catch (const std::runtime_error& e) {
22
std::cerr << "Error: " << e.what() << std::endl; // 捕获并处理异常
23
// 进行错误日志记录、用户提示等操作
24
}
25
return 0;
26
}
在上述例子中，readFile 函数尝试打开文件。如果文件打开失败，这是一种 非预期 的错误情况，程序无法继续读取文件内容。因此，函数抛出一个 std::runtime_error 异常来通知调用者文件打开失败。main 函数使用 try-catch 块捕获并处理这个异常，输出错误信息。
② 构造函数中的错误 (Errors in Constructors) 🏗️：
构造函数的主要职责是初始化对象，确保对象在创建后处于有效的状态。如果在构造过程中发生错误，例如资源分配失败、参数验证不通过等，此时构造函数 无法返回错误码，因为它没有返回值。异常是 唯一 能够从构造函数中报告错误的方式。
⚝ 资源分配失败 (Resource Allocation Failure)：在构造函数中需要分配内存、打开文件、获取系统资源等，如果分配失败，必须通过异常来通知对象创建失败。
⚝ 参数验证失败 (Parameter Validation Failure)：构造函数的参数可能需要满足特定的条件，如果参数不合法，应该抛出异常，阻止对象创建。
⚝ 对象状态初始化失败 (Object State Initialization Failure)：在某些情况下，对象的初始化依赖于外部条件，如果外部条件不满足，初始化失败，应该抛出异常。
通过在构造函数中抛出异常，可以确保 只有成功完成初始化的对象才会被创建出来，避免创建出处于无效状态的对象，从而维护程序的正确性。
1
#include <iostream>
2
#include <stdexcept>
3
4
class FileHandler {
5
private:
6
std::ofstream file_;
7
public:
8
FileHandler(const std::string& filename) {
9
file_.open(filename);
10
if (!file_.is_open()) {
11
// 构造函数中文件打开失败，抛出异常
12
throw std::runtime_error("Failed to open file in constructor: " + filename);
13
}
14
}
15
~FileHandler() {
16
if (file_.is_open()) {
17
file_.close();
18
}
19
}
20
void writeData(const std::string& data) {
21
if (!file_.is_open()) {
22
throw std::runtime_error("File is not open for writing.");
23
}
24
file_ << data << std::endl;
25
}
26
};
27
28
int main() {
29
try {
30
FileHandler handler("output.txt"); // 构造对象，可能抛出异常
31
handler.writeData("Hello, Exception!");
32
} catch (const std::runtime_error& e) {
33
std::cerr << "Constructor Error: " << e.what() << std::endl;
34
}
35
return 0;
36
}
在上述例子中，FileHandler 类的构造函数尝试打开指定的文件。如果文件打开失败，构造函数会抛出一个 std::runtime_error 异常。main 函数中的 try-catch 块可以捕获这个异常，表明 FileHandler 对象未能成功创建。
③ 深层嵌套函数调用中的错误 (Errors in Deeply Nested Function Calls) 🌊：
在复杂的程序中，函数调用可能存在多层嵌套。当错误发生在深层嵌套的函数中时，如果使用错误码逐层返回，代码会变得 冗余 且 难以维护。异常提供了一种更 优雅 的方式，可以直接将错误信息从深层函数 “抛” 到调用栈的上层，由最近的 catch 块进行处理。
⚝ 避免错误码的逐层传递 (Avoid Propagating Error Codes Layer by Layer)：使用错误码需要每个函数都检查返回值，并决定如何传递错误。这会导致大量的错误检查代码散布在程序的各个角落，降低代码的可读性。
⚝ 集中式错误处理 (Centralized Error Handling)：异常可以将错误处理逻辑集中在 catch 块中，使得代码结构更清晰，易于理解和维护。
⚝ 提高代码可读性 (Improve Code Readability)：使用异常可以使正常业务逻辑代码与错误处理代码分离，提高代码的整体可读性。
1
#include <iostream>
2
#include <stdexcept>
3
4
void functionC() {
5
// 深层函数 C
6
// ...
7
if (/* 发生错误条件 */ true) {
8
throw std::runtime_error("Error in functionC");
9
}
10
// ...
11
}
12
13
void functionB() {
14
// 中间层函数 B
15
functionC(); // 调用深层函数 C，可能抛出异常
16
// ...
17
}
18
19
void functionA() {
20
// 顶层函数 A
21
functionB(); // 调用中间层函数 B，可能传递异常
22
// ...
23
}
24
25
int main() {
26
try {
27
functionA(); // 从顶层函数开始调用
28
} catch (const std::runtime_error& e) {
29
std::cerr << "Caught exception in main: " << e.what() << std::endl;
30
}
31
return 0;
32
}
在上述例子中，错误发生在最深层的 functionC 中。functionC 直接抛出异常，异常沿着调用栈向上 传播，经过 functionB 和 functionA，最终在 main 函数的 catch 块中被捕获和处理。整个过程简洁明了，无需在 functionB 和 functionA 中编写额外的错误传递代码。
6.1.2 错误码的适用场景 (Use Cases for Error Codes)
小节概要
本小节将深入探讨错误码在 C++ 编程中的适用场景，并列举一系列典型用例，以帮助读者理解何时应当优先考虑使用错误码处理机制。我们将详细分析错误码在处理可预期错误、性能敏感场景以及跨语言/平台交互等方面的优势，并解释为何在这些情况下错误码能够提供更高效、更灵活的错误处理方案。
① 可预期的错误 (Expected Errors) 🤔：
错误码更适合用于处理那些在程序运行过程中 可预见 且 经常发生 的错误情况。这类错误通常是程序正常运行的一部分，例如：
⚝ 用户输入错误 (User Input Errors)：用户输入了格式错误的数据、无效的命令等。这些错误是用户操作不当引起的，程序应该能够 优雅地处理，并提示用户重新输入。
⚝ 文件不存在 (File Not Found)：程序尝试打开一个不存在的文件。虽然这可能是一个错误，但在某些情况下，例如程序需要检查文件是否存在，这可以被视为一种 正常情况。
⚝ 网络请求超时 (Network Request Timeout)：在网络通信中，请求超时是可能发生的，程序应该能够处理超时情况，并进行重试或其他操作。
对于这些 可预期 的错误，使用错误码可以避免异常处理的开销，提高程序的性能。同时，错误码的返回机制也更符合传统的 C 风格编程习惯。
1
#include <iostream>
2
#include <fstream>
3
#include <system_error> // 引入 system_error 支持错误码
4
5
std::error_code readFileWithErrorCode(const std::string& filename, std::string& content) {
6
std::ifstream file(filename);
7
if (!file.is_open()) {
8
// 文件打开失败，返回错误码
9
return std::make_error_code(std::io_errc::permission_denied); // 返回权限拒绝错误码，仅为示例
10
}
11
content.clear();
12
std::string line;
13
while (std::getline(file, line)) {
14
content += line + '\n';
15
}
16
file.close();
17
return std::error_code(); // 返回无错误码，表示成功
18
}
19
20
int main() {
21
std::string fileContent;
22
std::error_code ec = readFileWithErrorCode("my_file.txt", fileContent);
23
if (ec) {
24
// 检查错误码
25
std::cerr << "Error reading file: " << ec.message() << " (Category: " << ec.category().name() << ", Value: " << ec.value() << ")" << std::endl;
26
// 根据错误码进行相应的处理，例如重试、提示用户等
27
} else {
28
std::cout << "File content:\n" << fileContent << std::endl;
29
}
30
return 0;
31
}
在上述例子中，readFileWithErrorCode 函数使用 std::error_code 返回错误信息。如果文件打开失败，函数返回一个表示 权限拒绝 的错误码（这里仅为示例，实际应用中应根据具体错误类型返回相应的错误码）。main 函数检查返回的错误码，如果非空，则表示发生了错误，并输出错误信息。
② 性能敏感的场景 (Performance-Sensitive Scenarios) ⏱️：
在对性能要求 极高 的程序中，例如游戏引擎、实时系统、高性能服务器等，异常处理的开销可能会成为一个不可忽视的因素。虽然现代 C++ 编译器的异常处理实现已经非常高效，但在某些极端情况下，频繁地抛出和捕获异常仍然可能对性能产生影响。
⚝ 避免异常的 “零成本” 错觉 (Avoid the "Zero-Cost" Illusion of Exceptions)：虽然在没有异常抛出时，try-catch 块的开销很小，但一旦抛出异常，栈展开 (stack unwinding) 的过程会消耗一定的 CPU 时间。
⚝ 错误码的轻量级特性 (Lightweight Nature of Error Codes)：错误码本质上是一个整数值，返回和检查错误码的开销非常小，几乎可以忽略不计。
⚝ 替代方案：错误状态标志 (Error Status Flags)：在某些极端性能敏感的场景下，甚至可以使用更轻量级的错误状态标志 (flags) 来代替错误码，以进一步减少开销。
在这些 性能敏感 的场景中，如果错误是可预期的且经常发生的，使用错误码可以有效地降低错误处理的性能开销，提高程序的整体运行效率。
1
#include <iostream>
2
#include <chrono>
3
4
// 模拟一个可能频繁出错的性能敏感函数，使用错误码
5
int performanceSensitiveFunction(int input, int& output, int& errorCode) {
6
if (input < 0) {
7
errorCode = -1; // 错误码 -1 表示输入无效
8
return -1; // 函数本身也返回错误值，仅为示例
9
}
10
// 模拟一些计算密集型操作
11
output = input * 2;
12
errorCode = 0; // 错误码 0 表示成功
13
return 0; // 函数返回 0 表示成功，仅为示例
14
}
15
16
int main() {
17
auto startTime = std::chrono::high_resolution_clock::now();
18
int outputValue, errCode;
19
for (int i = 0; i < 1000000; ++i) {
20
performanceSensitiveFunction(i % 10 - 5, outputValue, errCode); // 模拟频繁调用，部分输入会出错
21
if (errCode != 0) {
22
// 处理错误码，但不抛出异常
23
// ...
24
}
25
}
26
auto endTime = std::chrono::high_resolution_clock::now();
27
auto duration = std::chrono::duration_cast<std::chrono::milliseconds>(endTime - startTime);
28
std::cout << "Function executed 1,000,000 times with error code handling in " << duration.count() << " milliseconds." << std::endl;
29
30
startTime = std::chrono::high_resolution_clock::now();
31
try {
32
for (int i = 0; i < 1000000; ++i) {
33
if (i % 10 - 5 < 0) {
34
throw std::runtime_error("Input out of range"); // 模拟使用异常处理
35
}
36
outputValue = (i % 10 - 5) * 2;
37
}
38
} catch (const std::runtime_error& e) {
39
// 捕获异常
40
// ...
41
}
42
endTime = std::chrono::high_resolution_clock::now();
43
duration = std::chrono::duration_cast<std::chrono::milliseconds>(endTime - startTime);
44
std::cout << "Function executed 1,000,000 times with exception handling in " << duration.count() << " milliseconds." << std::endl;
45
46
return 0;
47
}
在上述例子中，我们模拟了一个 performanceSensitiveFunction 函数，它在某些输入情况下会返回错误。我们分别使用错误码和异常处理的方式，对该函数进行了 100 万次调用，并测量了执行时间。在实际测试中，通常会发现使用错误码的版本在性能上略优于使用异常的版本，尤其是在错误频繁发生的情况下。虽然这只是一个简单的示例，但在 极端性能敏感 的场景下，这种性能差异可能会变得更加显著。
③ 需要跨语言或跨平台交互的场景 (Scenarios Requiring Cross-Language or Cross-Platform Interoperability) 🌉：
在需要与其他编程语言（如 C、Fortran、Python、Java 等）或跨不同平台（如 Windows、Linux、macOS 等）进行交互的场景中，异常处理机制可能会遇到兼容性问题。不同的语言和平台可能有不同的异常处理模型，C++ 的异常处理机制在某些情况下可能无法直接跨越语言或平台的边界。
⚝ C 语言的错误处理传统 (Error Handling Tradition in C)：C 语言主要使用错误码进行错误处理，缺乏原生的异常处理机制。与 C 代码进行交互时，通常需要使用错误码来进行错误传递。
⚝ 语言互操作性限制 (Language Interoperability Limitations)：不同语言的异常处理机制可能不兼容。例如，C++ 异常很难直接传递到 Java 或 Python 等语言环境中。
⚝ 平台差异性 (Platform Differences)：不同操作系统平台对异常处理的实现可能存在差异。在跨平台开发时，使用错误码可以提高代码的可移植性。
在这些 跨语言或跨平台交互 的场景中，为了保持兼容性和可移植性，使用错误码可能是一个更稳妥的选择。错误码作为一种通用的错误表示方式，更容易在不同的语言和平台之间进行传递和处理。
1
// C++ 代码，需要与 C 代码交互
2
3
#include <iostream>
4
#include <system_error>
5
6
// 假设有一个 C 函数，使用错误码返回结果
7
extern "C" int c_function(int input, int* output); // C 函数声明
8
9
std::error_code cppFunctionWrapper(int input, int& output) {
10
int errorCode = 0;
11
int result = c_function(input, &output); // 调用 C 函数
12
if (result != 0) {
13
// C 函数返回非零值表示错误，将其转换为 C++ 错误码
14
errorCode = result; // 假设 C 函数的错误码可以直接使用
15
switch (errorCode) { // 根据具体的错误码，映射到 C++ 标准错误码 (仅为示例)
16
case -1: return std::make_error_code(std::errc::invalid_argument);
17
case -2: return std::make_error_code(std::errc::permission_denied);
18
default: return std::make_error_code(std::errc::operation_failed);
19
}
20
}
21
return std::error_code(); // 返回无错误码，表示成功
22
}
23
24
int main() {
25
int outputValue;
26
std::error_code ec = cppFunctionWrapper(10, outputValue);
27
if (ec) {
28
std::cerr << "Error from C function: " << ec.message() << std::endl;
29
} else {
30
std::cout << "Result from C function: " << outputValue << std::endl;
31
}
32
return 0;
33
}
在上述例子中，C++ 代码需要调用一个使用错误码返回结果的 C 函数 c_function。C++ 代码通过一个包装函数 cppFunctionWrapper 来调用 C 函数，并将 C 函数的错误码转换为 C++ 的 std::error_code 对象。这样，C++ 代码就可以使用 C++ 的错误处理机制来处理来自 C 函数的错误，实现了跨语言的错误处理。
6.1.3 混合使用异常和错误码 (Mixing Exceptions and Error Codes)
小节概要
本小节将探讨在复杂的软件系统中，如何合理地混合使用异常和错误码，以达到最佳的错误处理效果。我们将分析混合使用两种机制的策略，并提供一些实践指导，帮助开发者在实际项目中灵活运用异常和错误码，构建更健壮、更高效的错误处理体系。
在实际的软件开发中，并不总是需要在异常和错误码之间做出非此即彼的选择。在某些复杂的系统中，混合使用 异常和错误码往往能够更好地平衡代码的 清晰度、性能 和 兼容性。
① 库的内部使用异常，接口使用错误码 (Exceptions Internally, Error Codes in Interfaces) 📦：
一种常见的混合使用策略是：库的内部实现 可以使用异常来处理错误，提高代码的可读性和维护性；而 库的公共接口 则使用错误码来向调用者报告错误，提高库的兼容性和性能。
⚝ 库内部的异常处理 (Exception Handling Inside Libraries)：库的内部代码可以使用异常来处理各种错误情况，例如资源分配失败、逻辑错误等。异常可以简化库的内部错误处理逻辑，提高代码的清晰度。
⚝ 库接口的错误码 (Error Codes in Library Interfaces)：库的公共接口，尤其是那些可能被其他语言或平台调用的接口，可以使用错误码来报告错误。错误码具有更好的跨语言和跨平台兼容性，同时也可以减少异常处理的性能开销。
⚝ 转换策略 (Translation Strategy)：在库的内部实现和公共接口之间，需要进行错误表示形式的转换。例如，库内部捕获到的异常可以被转换为相应的错误码，并通过接口返回给调用者；反之，从接口接收到的错误码可以被转换为异常，在库内部进行处理。
1
// 库头文件 (library.h)
2
3
#ifndef LIBRARY_H
4
#define LIBRARY_H
5
6
#include <system_error>
7
8
namespace mylib {
9
10
// 公共接口函数，使用错误码返回结果
11
std::error_code publicFunction(int input, int& output);
12
13
} // namespace mylib
14
15
#endif // LIBRARY_H
1
// 库实现文件 (library.cpp)
2
3
#include "library.h"
4
#include <stdexcept>
5
6
namespace mylib {
7
8
// 内部辅助函数，使用异常处理错误
9
int internalFunction(int input) {
10
if (input < 0) {
11
throw std::invalid_argument("Input must be non-negative"); // 内部抛出异常
12
}
13
return input * 2;
14
}
15
16
std::error_code publicFunction(int input, int& output) {
17
try {
18
output = internalFunction(input); // 调用内部函数，可能抛出异常
19
return std::error_code(); // 成功，返回无错误码
20
} catch (const std::invalid_argument& e) {
21
// 捕获内部异常，转换为错误码
22
return std::make_error_code(std::errc::invalid_argument);
23
} catch (const std::exception& e) {
24
// 捕获其他标准异常，转换为通用错误码
25
return std::make_error_code(std::errc::operation_failed);
26
} catch (...) {
27
// 捕获所有未知异常，转换为通用错误码
28
return std::make_error_code(std::errc::operation_failed);
29
}
30
}
31
32
} // namespace mylib
1
// 用户代码 (main.cpp)
2
3
#include "library.h"
4
#include <iostream>
5
6
int main() {
7
int result;
8
std::error_code ec = mylib::publicFunction(-5, result); // 调用库的公共接口
9
if (ec) {
10
std::cerr << "Error: " << ec.message() << std::endl; // 处理错误码
11
} else {
12
std::cout << "Result: " << result << std::endl;
13
}
14
return 0;
15
}
在上述例子中，mylib 库的内部实现使用了异常来处理错误，例如 internalFunction 函数在输入无效时会抛出 std::invalid_argument 异常。而库的公共接口 publicFunction 则使用错误码 std::error_code 来返回错误信息。publicFunction 函数内部使用 try-catch 块捕获 internalFunction 可能抛出的异常，并将其转换为相应的错误码返回给调用者。用户代码 main.cpp 只需要处理错误码，无需关心库内部的异常处理细节。
② 按错误类型选择错误处理机制 (Choosing Error Handling Mechanism by Error Type) 🎚️：
另一种混合使用策略是：根据错误的类型 来选择使用异常还是错误码。对于 非预期 的、严重的 错误，使用异常；对于 可预期 的、轻微的 错误，使用错误码。
⚝ 严重错误使用异常 (Exceptions for Severe Errors)：例如，资源耗尽、系统故障、逻辑不一致性等，这些错误表明程序运行环境或程序自身出现了严重问题，应该使用异常来 快速失败 (fail-fast)，并通知上层调用者进行处理。
⚝ 轻微错误使用错误码 (Error Codes for Minor Errors)：例如，用户输入错误、文件不存在、网络超时等，这些错误是程序正常运行过程中可能发生的，可以使用错误码来 优雅地处理，并允许程序继续运行。
⚝ 错误分类标准 (Error Classification Criteria)：如何区分严重错误和轻微错误，需要根据具体的应用场景来定义。一般来说，是否会导致程序状态严重破坏或无法继续正常运行 可以作为一个重要的判断标准。
1
#include <iostream>
2
#include <fstream>
3
#include <stdexcept>
4
#include <system_error>
5
6
// 函数：尝试读取文件内容，使用错误码处理文件不存在的情况，使用异常处理其他错误
7
std::error_code readFileContent(const std::string& filename, std::string& content) {
8
std::ifstream file(filename);
9
if (!file.is_open()) {
10
// 文件不存在，返回错误码 (可预期错误)
11
return std::make_error_code(std::io_errc::no_such_file_or_directory);
12
}
13
content.clear();
14
std::string line;
15
try {
16
while (std::getline(file, line)) {
17
content += line + '\n';
18
if (file.fail()) { // 检查其他可能的文件读取错误，例如 IO 错误
19
throw std::runtime_error("Error reading file content"); // 抛出异常 (非预期错误)
20
}
21
}
22
file.close();
23
} catch (const std::exception& e) {
24
file.close(); // 确保文件关闭
25
return std::make_error_code(std::errc::operation_failed); // 将异常转换为通用错误码
26
}
27
return std::error_code(); // 成功，返回无错误码
28
}
29
30
int main() {
31
std::string fileContent;
32
std::error_code ec = readFileContent("config.txt", fileContent);
33
if (ec) {
34
if (ec == std::make_error_code(std::io_errc::no_such_file_or_directory)) {
35
std::cout << "Warning: Configuration file not found, using default settings." << std::endl; // 警告，文件不存在，使用默认配置
36
// 程序可以继续运行，使用默认配置
37
} else {
38
std::cerr << "Error reading file: " << ec.message() << std::endl; // 其他文件读取错误，输出错误信息
39
// 程序可能无法继续正常运行，需要进行错误处理
40
}
41
} else {
42
std::cout << "Configuration file content:\n" << fileContent << std::endl; // 文件读取成功，使用文件内容
43
}
44
return 0;
45
}
在上述例子中，readFileContent 函数尝试读取文件内容。对于 文件不存在 这种 可预期 的错误，函数返回错误码 std::io_errc::no_such_file_or_directory。而对于其他 非预期 的文件读取错误（例如 IO 错误），函数会抛出 std::runtime_error 异常，并在 catch 块中将其转换为通用的错误码 std::errc::operation_failed 返回。main 函数根据返回的错误码类型，采取不同的处理策略：对于文件不存在的错误，程序可以继续运行并使用默认配置；对于其他文件读取错误，程序可能需要进行更严格的错误处理。
③ 在不同模块或层次中使用不同的错误处理机制 (Different Mechanisms in Different Modules or Layers) 🏢：
在大型的、模块化的系统中，不同的模块或软件层次可能采用不同的错误处理机制。例如，底层模块 可能更倾向于使用错误码，以提高性能和兼容性；高层模块 则可以使用异常，以提高代码的可读性和易维护性。
⚝ 底层模块的错误码 (Error Codes in Lower-Level Modules)：底层模块，例如操作系统接口、硬件驱动、网络协议栈等，通常对性能要求较高，且需要与其他系统组件进行交互。使用错误码可以减少开销，并提高兼容性。
⚝ 高层模块的异常 (Exceptions in Higher-Level Modules)：高层模块，例如应用逻辑、业务流程、用户界面等，更注重代码的可读性和开发效率。使用异常可以简化错误处理代码，提高开发效率。
⚝ 层次间的桥接 (Bridging Between Layers)：在不同错误处理机制的模块之间，需要进行适当的桥接。例如，底层模块返回的错误码可以被高层模块转换为异常，反之亦然。
这种分层处理错误的方式，可以根据不同模块的特点和需求，选择最合适的错误处理机制，从而构建一个既健壮又高效的系统。
1
// 底层模块 (low_level_module.cpp) - 使用错误码
2
3
#include <system_error>
4
5
namespace low_level {
6
7
std::error_code lowLevelOperation(int input, int& result) {
8
if (input < 0) {
9
return std::make_error_code(std::errc::invalid_argument);
10
}
11
result = input * 3;
12
return std::error_code();
13
}
14
15
} // namespace low_level
1
// 高层模块 (high_level_module.cpp) - 使用异常
2
3
#include "low_level_module.h"
4
#include <stdexcept>
5
6
namespace high_level {
7
8
int highLevelFunction(int input) {
9
int intermediateResult;
10
std::error_code ec = low_level::lowLevelOperation(input, intermediateResult); // 调用底层模块，获取错误码
11
if (ec) {
12
// 将底层错误码转换为异常抛出
13
throw std::runtime_error("Low-level operation failed: " + ec.message());
14
}
15
if (intermediateResult > 100) {
16
throw std::overflow_error("Intermediate result is too large"); // 高层模块自身的异常
17
}
18
return intermediateResult + 10;
19
}
20
21
} // namespace high_level
1
// 应用代码 (app.cpp)
2
3
#include "high_level_module.h"
4
#include <iostream>
5
6
int main() {
7
try {
8
int finalResult = high_level::highLevelFunction(5); // 调用高层模块，可能抛出异常
9
std::cout << "Final result: " << finalResult << std::endl;
10
} catch (const std::exception& e) {
11
std::cerr << "Error in high-level function: " << e.what() << std::endl;
12
}
13
return 0;
14
}
在上述例子中，low_level 模块作为底层模块，使用错误码 std::error_code 来报告错误。high_level 模块作为高层模块，则使用异常来处理错误。highLevelFunction 函数调用了底层模块的 lowLevelOperation 函数，并检查其返回的错误码。如果底层操作失败，highLevelFunction 会将底层错误码转换为异常 std::runtime_error 抛出。同时，highLevelFunction 自身也可能抛出 std::overflow_error 异常。应用代码 app.cpp 只需要处理高层模块抛出的异常，无需直接处理底层模块的错误码。
通过以上分析，我们可以看到，异常和错误码各有其适用场景和优势。在实际开发中，开发者需要根据具体的应用需求、性能要求、兼容性考虑以及代码风格偏好，灵活地选择和组合使用这两种错误处理机制，才能构建出更加健壮、高效、易于维护的 C++ 软件系统。
7. 高级异常处理技巧 (Advanced Exception Handling Techniques)
章节概要
本章将深入探讨 C++ 异常处理的一些高级技巧，旨在帮助读者更好地应对复杂的异常场景。我们将涵盖嵌套异常 (Nested Exceptions)、异常转换 (Exception Translation) 以及多线程环境 (Multithreaded Environments) 下的异常处理。掌握这些高级技巧能够提升程序的健壮性、灵活性和可维护性。
7.1 嵌套异常 (Nested Exceptions)
嵌套异常 (Nested Exceptions) 指的是在一个异常处理的过程中，由于某种原因又抛出了新的异常。这种情况可能发生在 catch 块内部，或者在处理异常的过程中调用的函数又抛出了异常。理解和处理嵌套异常对于调试和诊断复杂错误至关重要。
7.1.1 什么是嵌套异常？(What are Nested Exceptions?)
嵌套异常 (Nested Exceptions) 发生在当程序正在处理一个异常时，又遇到了另一个异常。 考虑以下情景：
① 在 try 块中，函数 func1() 抛出一个异常 ExceptionA。
② catch 块捕获 ExceptionA 并尝试进行错误处理。
③ 在 catch 块的处理逻辑中，调用了函数 func2()。
④ func2() 在执行过程中又抛出了一个新的异常 ExceptionB。
此时，ExceptionB 就成为了嵌套在 ExceptionA 处理过程中的异常。 如果不妥善处理，可能会导致原始异常信息丢失，或者程序行为变得难以预测。
示例代码：
1
#include <iostream>
2
#include <stdexcept>
3
4
void func2() {
5
throw std::runtime_error("Exception from func2"); // 抛出 ExceptionB
6
}
7
8
void func1() {
9
try {
10
// ... 一些可能抛出异常的代码 ...
11
throw std::runtime_error("Exception from func1"); // 抛出 ExceptionA
12
} catch (const std::runtime_error& e) {
13
std::cerr << "Caught exception in func1: " << e.what() << std::endl;
14
func2(); // 在异常处理中调用 func2，可能抛出 ExceptionB
15
}
16
}
17
18
int main() {
19
try {
20
func1();
21
} catch (const std::runtime_error& e) {
22
std::cerr << "Caught exception in main: " << e.what() << std::endl; // 只能捕获到 func2 抛出的异常，原始异常信息丢失
23
}
24
return 0;
25
}
在上述代码中，func1() 尝试捕获并处理其内部抛出的异常，但在处理过程中又调用了 func2()，而 func2() 也抛出了异常。 在 main() 函数的 catch 块中，我们只能捕获到 func2() 抛出的异常，而 func1() 原始抛出的异常信息则丢失了。 这就是嵌套异常带来的问题。
7.1.2 std::nested_exception 和 std::current_exception() (std::nested_exception and std::current_exception())
为了解决嵌套异常导致原始异常信息丢失的问题，C++ 标准库提供了 std::nested_exception 类和 std::current_exception() 函数。
① std::nested_exception: 这个类本身是一个异常类，它可以包装另一个异常。 通过继承 std::nested_exception，我们可以创建一个异常类，使其能够存储“引发”它的原始异常。
② std::current_exception(): 这个函数返回一个 std::exception_ptr，指向当前正在处理的异常。 如果当前没有正在处理的异常，则返回空的 std::exception_ptr。 这个函数通常在 catch 块中使用，用来捕获当前异常，并将其存储起来，以便后续处理。
如何使用 std::nested_exception 和 std::current_exception() 来处理嵌套异常？
在 catch 块中，如果需要抛出一个新的异常，并且希望保留原始异常的信息，可以这样做：
① 捕获当前异常：使用 std::current_exception() 获取当前异常的 std::exception_ptr。
② 创建自定义的嵌套异常类： 自定义的异常类需要继承自 std::nested_exception，并在构造函数中接受并存储原始异常的 std::exception_ptr。
③ 抛出嵌套异常： 在 catch 块中抛出自定义的嵌套异常对象。
④ 在更外层的 catch 块中解包和处理嵌套异常： 可以使用 std::nested_exception 提供的接口（例如 nested_ptr()）来访问和处理原始异常。
自定义嵌套异常类示例:
1
#include <iostream>
2
#include <stdexcept>
3
#include <exception>
4
5
class MyNestedException : public std::runtime_error, public std::nested_exception {
6
public:
7
MyNestedException(const std::string& message, std::exception_ptr cause)
8
: std::runtime_error(message), nested_exception(cause) {}
9
};
这个 MyNestedException 类同时继承自 std::runtime_error 和 std::nested_exception。 它接受一个 std::exception_ptr 参数 cause，用于存储原始异常。
7.1.3 处理嵌套异常的示例 (Examples of Handling Nested Exceptions)
现在，让我们修改之前的 func1() 和 main() 函数，使用 std::nested_exception 和 std::current_exception() 来处理嵌套异常，并保留原始异常信息。
修改后的代码:
1
#include <iostream>
2
#include <stdexcept>
3
#include <exception>
4
5
class MyNestedException : public std::runtime_error, public std::nested_exception {
6
public:
7
MyNestedException(const std::string& message, std::exception_ptr cause)
8
: std::runtime_error(message), nested_exception(cause) {}
9
};
10
11
void func2() {
12
throw std::runtime_error("Exception from func2");
13
}
14
15
void func1() {
16
try {
17
throw std::runtime_error("Exception from func1");
18
} catch (const std::runtime_error& e) {
19
std::cerr << "Caught exception in func1: " << e.what() << std::endl;
20
try {
21
func2();
22
} catch (...) {
23
// 捕获 func2 的异常，并将其作为 cause 包装到 MyNestedException 中
24
throw MyNestedException("Nested exception in func1", std::current_exception());
25
}
26
}
27
}
28
29
void print_nested_exceptions(const std::exception& e) {
30
std::cerr << "Exception: " << e.what() << std::endl;
31
try {
32
std::rethrow_if_nested(e); // 检查是否是 nested_exception，如果是则 rethrow 嵌套的异常
33
} catch (const std::nested_exception& nested_e) {
34
std::cerr << "Nested exception caught:" << std::endl;
35
print_nested_exceptions(nested_e); // 递归打印嵌套异常
36
} catch (...) {
37
// 不是 nested_exception，停止递归
38
}
39
}
40
41
42
int main() {
43
try {
44
func1();
45
} catch (const std::exception& e) {
46
std::cerr << "Caught exception in main:" << std::endl;
47
print_nested_exceptions(e); // 打印异常信息，包括嵌套异常
48
}
49
return 0;
50
}
代码解释:
① MyNestedException: 自定义的嵌套异常类，继承自 std::runtime_error 和 std::nested_exception。
② func1() 的 catch 块:
▮▮▮▮⚝ 内部 try-catch 块尝试调用 func2()。
▮▮▮▮⚝ 如果 func2() 抛出异常，内部 catch(...) 捕获所有异常。
▮▮▮▮⚝ 使用 std::current_exception() 获取 func2() 抛出的异常的 std::exception_ptr。
▮▮▮▮⚝ 抛出 MyNestedException，并将 func2() 的异常作为 cause 传递给 MyNestedException 的构造函数。
③ print_nested_exceptions() 函数:
▮▮▮▮⚝ 接收一个 std::exception 对象引用。
▮▮▮▮⚝ 打印当前异常的 what() 信息。
▮▮▮▮⚝ 使用 std::rethrow_if_nested(e) 检查 e 是否是 std::nested_exception 的实例。
▮▮▮▮⚝ 如果是，std::rethrow_if_nested(e) 会重新抛出 被包装的异常。 catch (const std::nested_exception& nested_e) 捕获这个被包装的异常。
▮▮▮▮⚝ 递归调用 print_nested_exceptions(nested_e) 来打印嵌套异常的信息。
▮▮▮▮⚝ 如果不是 std::nested_exception，则 std::rethrow_if_nested(e) 不会抛出异常，递归结束。
④ main() 函数的 catch 块:
▮▮▮▮⚝ 捕获 func1() 可能抛出的 std::exception 类型异常（包括 MyNestedException）。
▮▮▮▮⚝ 调用 print_nested_exceptions() 函数来打印异常信息，包括所有嵌套的异常信息。
运行结果:
1
Caught exception in func1: Exception from func1
2
Caught exception in main:
3
Exception: Nested exception in func1
4
Nested exception caught:
5
Exception: Exception from func2
可以看到，通过 std::nested_exception 和 std::current_exception()，我们成功地捕获并保留了嵌套异常的信息，并通过 print_nested_exceptions() 函数递归地打印了所有异常的信息，包括原始异常 "Exception from func1" 和嵌套异常 "Exception from func2"。 这对于调试复杂的异常链非常有用。
7.2 异常转换 (Exception Translation)
异常转换 (Exception Translation) 指的是在一个异常处理的边界，将捕获到的一种类型的异常转换为另一种类型的异常再抛出。 异常转换通常发生在不同的软件层级或模块之间，目的是为了：
① 隐藏底层实现细节: 避免将底层的异常类型暴露给上层模块，保持接口的稳定性和抽象性。
② 提供更具业务含义的异常: 将技术性的底层异常（例如文件 IO 错误）转换为更贴近业务逻辑的异常（例如 "订单处理失败"）。
③ 统一异常类型: 在跨越多个模块或库的边界时，将不同来源的异常统一转换为一组预定义的异常类型，方便上层统一处理。
7.2.1 异常转换的应用场景 (Use Cases for Exception Translation)
① 库接口设计: 当设计一个库时，库的内部实现可能会使用各种底层的异常类型。 为了保持库接口的稳定性和易用性，库的公共接口通常会将内部的底层异常转换为一组库自身定义的、更高级别的异常类型。 这样，库的使用者只需要关注库文档中明确定义的异常类型，而无需了解库内部复杂的异常细节。
② 模块边界: 在大型软件系统中，不同的模块可能由不同的团队开发，并使用不同的异常处理策略。 在模块边界处进行异常转换，可以将一个模块的异常处理方式与另一个模块隔离，避免模块之间的异常处理策略相互影响。
③ 错误码到异常的转换: 在一些遗留代码或 C 风格的接口中，错误处理可能使用错误码而不是异常。 为了与现代 C++ 的异常处理机制整合，可以将错误码转换为异常抛出。 反之，在需要与 C 风格的接口交互时，也可能需要将异常转换为错误码。
④ 异常细化与泛化: 有时，我们需要将一个通用的异常类型转换为更具体的异常类型，以提供更详细的错误信息。 例如，可以将 std::exception 转换为 FileNotFoundException 或 NetworkException。 反之，也可能需要将多个具体的异常类型泛化为一个更通用的异常类型，以便上层进行统一处理。
7.2.2 实现异常转换的方法 (Methods for Implementing Exception Translation)
实现异常转换的主要方法是在 catch 块中捕获原始异常，然后根据需要创建并抛出新的异常。
基本步骤:
① 捕获原始异常: 在 try-catch 块中捕获需要转换的异常类型。 可以使用具体的异常类型，也可以使用 catch(...) 捕获所有异常。
② 决定新的异常类型: 根据应用场景和转换目的，选择或自定义新的异常类型。 新的异常类型应该更符合上层模块的需求或业务逻辑。
③ 创建并抛出新的异常: 在 catch 块中，根据原始异常的信息，创建新的异常对象，并使用 throw 语句抛出新的异常。 在创建新的异常对象时，可以将原始异常的信息（例如错误消息、错误代码等）传递给新的异常对象，以便保留原始错误上下文。
示例代码框架:
1
try {
2
// ... 可能抛出原始异常的代码 ...
3
} catch (const OriginalExceptionType& originalException) {
4
// ... 异常转换逻辑 ...
5
// 1. 获取原始异常的信息 (例如 originalException.what())
6
std::string errorMessage = "Error in module X: " + originalException.what();
7
8
// 2. 创建新的异常对象 (NewExceptionType)
9
NewExceptionType newException(errorMessage);
10
11
// 3. 抛出新的异常
12
throw newException;
13
} catch (...) { // 可选的 catch(...) 处理其他未预期的异常
14
// ... 其他异常处理或默认转换逻辑 ...
15
throw; // 或者抛出一个默认的异常类型
16
}
在 catch (const OriginalExceptionType& originalException) 块中，我们捕获了 OriginalExceptionType 类型的原始异常。 然后，我们根据原始异常的信息，创建了一个 NewExceptionType 类型的新的异常对象，并将其抛出。 这样就完成了从 OriginalExceptionType 到 NewExceptionType 的异常转换。
7.2.3 异常转换的示例 (Examples of Exception Translation)
示例 1: 底层 IO 异常转换为业务异常
假设我们有一个文件处理模块，底层使用了 std::ifstream 进行文件读取，可能会抛出 std::ifstream::failure 等 IO 相关的异常。 我们希望将这些底层的 IO 异常转换为更具业务含义的异常，例如 FileCorruptedError 或 DataFormatError。
1
#include <iostream>
2
#include <fstream>
3
#include <stdexcept>
4
#include <string>
5
6
class FileCorruptedError : public std::runtime_error {
7
public:
8
FileCorruptedError(const std::string& filename)
9
: std::runtime_error("File corrupted: " + filename) {}
10
};
11
12
class DataFormatError : public std::runtime_error {
13
public:
14
DataFormatError(const std::string& message)
15
: std::runtime_error("Data format error: " + message) {}
16
};
17
18
void process_file_data(const std::string& filename) {
19
std::ifstream inputFile(filename);
20
if (!inputFile.is_open()) {
21
throw std::runtime_error("Failed to open file: " + filename); // 保持 std::runtime_error 用于文件打开失败
22
}
23
24
try {
25
std::string line;
26
while (std::getline(inputFile, line)) {
27
// ... 解析和处理文件数据的逻辑 ...
28
if (line.find("INVALID_DATA") != std::string::npos) {
29
throw DataFormatError("Invalid data format found in file: " + filename); // 抛出 DataFormatError
30
}
31
// ... 其他数据处理 ...
32
}
33
} catch (const std::ifstream::failure& e) {
34
// 捕获 std::ifstream::failure，转换为 FileCorruptedError
35
throw FileCorruptedError(filename);
36
} catch (const DataFormatError& e) {
37
throw; // DataFormatError 本身已经是业务异常，直接 rethrow
38
} catch (const std::exception& e) {
39
throw; // 其他 std::exception 类型的异常，也 rethrow，可以根据需要进行更细致的转换
40
}
41
}
42
43
int main() {
44
try {
45
process_file_data("data.txt");
46
} catch (const FileCorruptedError& e) {
47
std::cerr << "Error: " << e.what() << std::endl;
48
// ... 处理文件损坏错误 ...
49
} catch (const DataFormatError& e) {
50
std::cerr << "Error: " << e.what() << std::endl;
51
// ... 处理数据格式错误 ...
52
} catch (const std::exception& e) {
53
std::cerr << "Unexpected error: " << e.what() << std::endl;
54
// ... 处理其他未预期的异常 ...
55
}
56
return 0;
57
}
在这个示例中，process_file_data() 函数内部使用了 std::ifstream 进行文件读取。 在 catch (const std::ifstream::failure& e) 块中，我们将 std::ifstream::failure 异常转换为了 FileCorruptedError 业务异常。 DataFormatError 异常本身已经是业务异常，所以直接 rethrow。 其他 std::exception 类型的异常也选择 rethrow， 在实际应用中，可以根据需要进行更细致的转换。 main() 函数的 catch 块针对不同的业务异常类型进行处理。
示例 2: 统一库接口的异常类型
假设我们正在开发一个网络库，库的内部实现可能使用了多种不同的网络协议和库，这些底层库可能会抛出各种各样的异常类型。 为了统一库接口的异常处理，我们可以将底层库的异常转换为一组库自身定义的、统一的网络异常类型，例如 NetworkError, ConnectionError, TimeoutError 等。 这样，库的使用者只需要处理这些统一的异常类型，而无需关心底层网络实现的细节。 具体的实现方式与示例 1 类似，只需定义一组网络异常类，并在库的接口处进行异常转换即可。
异常转换的注意事项:
① 避免信息丢失: 在进行异常转换时，要尽量保留原始异常的信息，例如错误消息、错误代码等。 可以将原始异常的信息作为新异常对象的一部分进行存储和传递，可以使用嵌套异常的技术来保存原始异常的上下文。
② 转换的合理性: 异常转换应该是有意义的。 要根据应用场景和转换目的，选择合适的新的异常类型。 避免进行不必要的或误导性的异常转换。
③ 文档化: 如果库或模块进行了异常转换，需要在文档中明确说明哪些原始异常会被转换为哪些新的异常类型。 方便库或模块的使用者正确地处理异常。
7.3 多线程环境下的异常处理 (Exception Handling in Multithreaded Environments)
在多线程 (Multithreaded) 程序中，异常处理变得更加复杂，因为我们需要考虑线程之间的异常传播、线程局部存储 (Thread-Local Storage, TLS) 与异常安全、以及异步异常处理 (Asynchronous Exception Handling) 等问题。
7.3.1 线程间异常的传播 (Exception Propagation Between Threads)
默认情况下，C++ 中的异常不会跨线程传播。 当一个线程抛出异常时，异常只能在该线程的调用栈中进行查找 catch 块。 如果该线程的调用栈中没有合适的 catch 块来处理异常，则程序会调用 std::terminate() 终止。 异常不会自动传递到创建该线程的线程，或者其他任何线程。
这意味着，每个线程都需要负责处理自己内部抛出的异常。 如果在多线程程序中，子线程可能会抛出异常，而主线程需要知道子线程是否发生了错误，并进行相应的处理，就需要使用一些显式的机制来在线程之间传递异常信息。
常用的线程间异常传播方法:
① 使用 std::future 和 std::promise: std::future 和 std::promise 是 C++ 标准库中用于异步操作结果传递的工具。 std::promise 可以设置一个值或一个异常，std::future 可以获取这个值或异常。 如果子线程在执行任务时抛出了异常，可以将这个异常存储到 std::promise 中，然后在主线程中通过 std::future::get() 获取结果时，如果 std::promise 中存储的是异常，std::future::get() 会重新抛出这个异常，从而将子线程的异常传播到主线程。
② 使用回调函数或信号量: 可以定义一个回调函数或使用信号量，当子线程捕获到异常时，通过回调函数或信号量通知主线程发生了错误，并在回调函数或信号量处理逻辑中传递异常信息（例如错误码、错误消息等）。
③ 使用全局错误队列: 可以创建一个全局的错误队列，当子线程捕获到异常时，将异常信息放入队列中，主线程定期检查队列，获取子线程的错误信息并进行处理。 这种方法需要注意线程安全问题，需要使用互斥锁等同步机制来保护错误队列的访问。
示例：使用 std::future 和 std::promise 传播线程异常:
1
#include <iostream>
2
#include <thread>
3
#include <future>
4
#include <stdexcept>
5
6
int task_function() {
7
// ... 一些可能抛出异常的任务 ...
8
throw std::runtime_error("Exception from task thread"); // 子线程抛出异常
9
return 42;
10
}
11
12
int main() {
13
std::promise<int> promise;
14
std::future<int> future = promise.get_future();
15
16
std::thread task_thread([&promise]() {
17
try {
18
int result = task_function();
19
promise.set_value(result); // 任务成功完成，设置 promise 的值
20
} catch (...) {
21
promise.set_exception(std::current_exception()); // 任务发生异常，设置 promise 的异常
22
}
23
});
24
25
try {
26
int result = future.get(); // 获取任务结果，如果 promise 中存储的是异常，get() 会重新抛出异常
27
std::cout << "Task result: " << result << std::endl;
28
} catch (const std::exception& e) {
29
std::cerr << "Caught exception from task thread in main thread: " << e.what() << std::endl;
30
// ... 主线程处理子线程的异常 ...
31
}
32
33
task_thread.join();
34
return 0;
35
}
在这个示例中，子线程 task_thread 执行 task_function()。 如果 task_function() 抛出异常，在子线程的 catch (...) 块中，使用 promise.set_exception(std::current_exception()) 将当前异常存储到 promise 中。 在主线程中，future.get() 尝试获取任务结果。 由于 promise 中存储的是异常，future.get() 会重新抛出这个异常，从而将子线程的异常传播到主线程的 catch 块中进行处理。
7.3.2 线程局部存储与异常安全 (Thread-Local Storage and Exception Safety)
线程局部存储 (Thread-Local Storage, TLS) 允许每个线程拥有独立的变量副本。 在多线程程序中，如果使用了 TLS，需要特别注意异常安全问题，确保在异常发生时，线程局部资源能够被正确地清理和释放，避免资源泄漏或数据不一致。
RAII (Resource Acquisition Is Initialization) 原则在线程局部存储的异常安全管理中仍然非常重要。 可以使用 RAII 封装线程局部变量的生命周期管理，确保在线程退出（正常退出或异常退出）时，线程局部资源能够被自动释放。
示例：使用 RAII 管理线程局部资源:
1
#include <iostream>
2
#include <thread>
3
#include <memory>
4
5
// 线程局部资源管理类
6
class ThreadLocalResource {
7
public:
8
ThreadLocalResource() {
9
std::cout << "ThreadLocalResource constructed in thread " << std::this_thread::get_id() << std::endl;
10
// ... 初始化线程局部资源 ...
11
}
12
~ThreadLocalResource() {
13
std::cout << "ThreadLocalResource destructed in thread " << std::this_thread::get_id() << std::endl;
14
// ... 释放线程局部资源 ...
15
}
16
17
void useResource() {
18
std::cout << "Using thread local resource in thread " << std::this_thread::get_id() << std::endl;
19
// ... 使用线程局部资源 ...
20
if (rand() % 3 == 0) {
21
throw std::runtime_error("Exception while using thread local resource"); // 模拟异常
22
}
23
}
24
};
25
26
thread_local std::unique_ptr<ThreadLocalResource> tls_resource; // 声明线程局部变量
27
28
void thread_function() {
29
tls_resource = std::make_unique<ThreadLocalResource>(); // 初始化线程局部资源 (RAII)
30
try {
31
tls_resource->useResource();
32
} catch (const std::exception& e) {
33
std::cerr << "Caught exception in thread " << std::this_thread::get_id() << ": " << e.what() << std::endl;
34
// ... 线程内部异常处理 ...
35
}
36
// tls_resource 的 unique_ptr 在线程函数结束时析构，自动释放线程局部资源 (RAII)
37
}
38
39
int main() {
40
std::thread t1(thread_function);
41
std::thread t2(thread_function);
42
43
t1.join();
44
t2.join();
45
return 0;
46
}
在这个示例中，ThreadLocalResource 类封装了线程局部资源的生命周期管理。 tls_resource 被声明为 thread_local std::unique_ptr<ThreadLocalResource>，这意味着每个线程都会拥有 tls_resource 的独立副本，并且 tls_resource 是一个智能指针 std::unique_ptr，利用 RAII 原则进行资源管理。
在 thread_function() 中，使用 std::make_unique<ThreadLocalResource>() 初始化线程局部资源，并将其赋值给 tls_resource。 在 try-catch 块中尝试使用线程局部资源，即使在 useResource() 函数中抛出异常，tls_resource 的 std::unique_ptr 也会在 thread_function() 函数结束时被析构，从而自动调用 ThreadLocalResource 的析构函数，释放线程局部资源，保证了异常安全。
7.3.3 异步异常处理 (Asynchronous Exception Handling)
异步异常处理 (Asynchronous Exception Handling) 指的是在异步操作中处理异常。 异步操作通常使用 std::async, std::future, std::promise 等工具来实现。 在异步操作中，异常可能在异步任务的执行线程中抛出，而异常处理的代码可能需要在主线程或其他线程中执行。 线程间异常传播 (7.3.1 节) 中介绍的 std::future 和 std::promise 机制，就是一种常用的异步异常处理方法。
除了 std::future 和 std::promise，还可以使用其他异步编程模型和库来处理异步异常，例如:
① 回调函数: 在异步操作完成时调用回调函数，回调函数可以接收操作结果或异常信息。 如果异步操作发生异常，可以在回调函数中处理异常。
② 事件或信号: 异步操作完成时触发事件或发送信号，事件或信号的处理函数可以获取操作结果或异常信息。
③ async/await (C++20): C++20 引入了 async/await 关键字，可以更方便地编写异步代码，并使用 try-catch 块来处理异步操作中的异常，代码结构更接近同步代码，提高了可读性和易用性。 co_await 表达式如果等待的协程返回的是一个异常，co_await 表达式会重新抛出这个异常，可以在 try-catch 块中捕获和处理。
示例：使用 std::async 和 std::future 进行异步异常处理:
1
#include <iostream>
2
#include <future>
3
#include <stdexcept>
4
#include <chrono>
5
#include <thread>
6
7
int async_task() {
8
std::cout << "Async task started in thread " << std::this_thread::get_id() << std::endl;
9
std::this_thread::sleep_for(std::chrono::seconds(2)); // 模拟耗时操作
10
if (rand() % 2 == 0) {
11
throw std::runtime_error("Exception from async task"); // 异步任务中抛出异常
12
}
13
std::cout << "Async task finished successfully in thread " << std::this_thread::get_id() << std::endl;
14
return 100;
15
}
16
17
int main() {
18
std::future<int> future_result = std::async(std::launch::async, async_task); // 启动异步任务
19
20
try {
21
int result = future_result.get(); // 获取异步任务结果，如果异步任务抛出异常，get() 会重新抛出异常
22
std::cout << "Async task result in main thread: " << result << std::endl;
23
} catch (const std::exception& e) {
24
std::cerr << "Caught exception from async task in main thread: " << e.what() << std::endl;
25
// ... 主线程处理异步任务的异常 ...
26
}
27
28
return 0;
29
}
在这个示例中，使用 std::async(std::launch::async, async_task) 启动了一个异步任务 async_task()。 std::async 返回一个 std::future<int> 对象 future_result。 在 main() 函数中，调用 future_result.get() 来获取异步任务的结果。 如果 async_task() 在执行过程中抛出了异常，future_result.get() 会重新抛出这个异常，从而可以在 main() 函数的 try-catch 块中捕获和处理异步任务的异常。 std::launch::async 参数确保 async_task() 在一个新的线程中异步执行。
总结:
在多线程环境下进行异常处理，需要特别关注线程间异常的传播、线程局部存储的异常安全管理、以及异步异常处理。 合理使用 std::future 和 std::promise、RAII 原则、以及异步编程模型，可以有效地解决多线程环境下的异常处理问题，提高多线程程序的健壮性和可靠性。
8. 案例分析与实战 (Case Studies and Practical Applications)
8.1 文件操作中的异常处理 (Exception Handling in File Operations)
8.1.1 文件打开异常 (File Open Exceptions)
在文件操作中，文件打开 (File Open) 是首要步骤，但也可能遇到各种异常情况。例如，尝试打开一个不存在的文件、没有足够的权限访问文件、或者文件被其他程序占用等。C++ 的文件流 (File Stream) std::fstream 及其相关类在遇到这些问题时，通常会设置内部错误标志位，而不是直接抛出异常。然而，为了更好地利用 C++ 异常处理机制，我们可以配置文件流在遇到错误时抛出异常，或者手动检查错误状态并抛出自定义异常。
① 常见的文件打开异常场景:
▮▮▮▮ⓐ 文件不存在 (File Not Found): 尝试打开一个路径不存在的文件。这在用户输入错误路径或文件被删除时很常见。
▮▮▮▮ⓑ 权限不足 (Permission Denied): 程序没有足够的权限读取或写入目标文件。这通常发生在访问受保护的系统文件或用户没有适当权限的目录时。
▮▮▮▮ⓒ 文件被占用 (File in Use): 尝试以独占模式打开已被其他程序或进程打开的文件。
▮▮▮▮ⓓ 磁盘空间不足 (Disk Full): 虽然不直接是文件打开异常，但在某些情况下，如果文件系统接近满容量，可能会影响文件打开操作，尤其是在创建新文件或以写入模式打开文件时。
▮▮▮▮ⓔ 硬件故障 (Hardware Failure): 磁盘驱动器或其他硬件故障可能导致文件系统错误，从而阻止文件打开。
② 处理文件打开异常的方法:
C++ 文件流对象（如 std::ifstream, std::ofstream, std::fstream）提供了 exceptions() 方法来设置在哪些错误条件下抛出异常。我们可以使用 failbit, badbit, eofbit 等标志来控制异常行为。
1
#include <iostream>
2
#include <fstream>
3
#include <stdexcept> // for std::runtime_error, std::ios_base::failure
4
5
int main() {
6
std::string filename = "non_existent_file.txt";
7
std::ifstream inputFile(filename);
8
9
// 配置 inputFile 在 failbit 和 badbit 置位时抛出异常
10
inputFile.exceptions(std::ifstream::failbit | std::ifstream::badbit);
11
12
try {
13
if (!inputFile.is_open()) {
14
throw std::runtime_error("Failed to open file: " + filename); // 手动检查并抛出异常 (如果 exceptions() 未配置)
15
}
16
17
std::string line;
18
while (std::getline(inputFile, line)) {
19
std::cout << line << std::endl;
20
}
21
inputFile.close(); // 即使发生异常，RAII 也会处理关闭，但显式关闭是好习惯
22
23
} catch (const std::ios_base::failure& e) {
24
std::cerr << "I/O exception caught: " << e.what() << std::endl;
25
if (e.bad()) {
26
std::cerr << " Stream is in a bad state." << std::endl;
27
} else if (e.fail()) {
28
std::cerr << " Logical I/O operation failure on stream." << std::endl; // 文件打开失败通常是 failbit
29
}
30
// 可以根据具体异常类型进行更详细的处理
31
} catch (const std::runtime_error& e) {
32
std::cerr << "Runtime error: " << e.what() << std::endl; // 处理手动抛出的异常
33
} catch (...) {
34
std::cerr << "Unknown exception caught during file operation." << std::endl; // 捕获其他未知异常
35
}
36
37
return 0;
38
}
在这个例子中，我们首先使用 inputFile.exceptions(std::ifstream::failbit | std::ifstream::badbit); 配置 inputFile 流，使其在 failbit 或 badbit 被设置时抛出 std::ios_base::failure 类型的异常。 failbit 通常在逻辑操作失败时设置（例如，文件不存在），而 badbit 通常在严重的流错误（例如，硬件故障）发生时设置。
在 try 块中，我们尝试打开文件。即使我们配置了异常抛出，手动检查 inputFile.is_open() 仍然是一个好的实践，尤其是在没有配置 exceptions() 或者需要抛出自定义异常类型的情况下。如果文件未能成功打开（例如，is_open() 返回 false），我们手动抛出一个 std::runtime_error 异常，提供更具描述性的错误信息。
catch 块部分，我们首先捕获 std::ios_base::failure 类型的异常，这是由文件流自身抛出的异常类型。通过检查 e.what() 可以获取基本的错误描述。我们可以进一步检查 e.bad() 和 e.fail() 来区分不同类型的 I/O 错误。 之后，我们捕获手动抛出的 std::runtime_error 异常，以及一个通用的 catch(...) 块来捕获任何其他未预料到的异常，确保程序的健壮性。
③ 最佳实践:
⚝ 配置异常标志: 使用 exceptions() 方法配置文件流在遇到错误时抛出异常，可以简化错误处理代码，使其更清晰和集中。
⚝ 具体异常类型: 捕获 std::ios_base::failure 及其派生类，可以更精确地处理 I/O 相关的错误。
⚝ 自定义异常: 对于特定的应用场景，可以考虑抛出自定义的异常类型，以提供更丰富的错误信息，例如包含文件名、操作类型等。
⚝ RAII 与文件流: 文件流对象本身就是 RAII (Resource Acquisition Is Initialization) 的体现，当文件流对象超出作用域时，其析构函数会自动关闭文件，即使在异常情况下也能确保资源被释放。
通过合理地使用异常处理机制，我们可以有效地处理文件打开过程中可能出现的各种问题，提高程序的可靠性和用户体验。
8.1.2 文件读写异常 (File Read/Write Exceptions)
文件读写操作是文件处理的核心部分，但在这个过程中，同样可能遇到各种异常情况。与文件打开类似，文件读写操作的异常也需要妥善处理，以保证数据的完整性和程序的稳定性。
① 常见的文件读写异常场景:
▮▮▮▮ⓐ 读取超出文件末尾 (End-of-File during Read): 尝试读取数据时，已经到达文件末尾。这通常不是一个错误，而是一个正常的结束条件，但如果程序逻辑期望读取更多数据，则可能被视为异常情况。
▮▮▮▮ⓑ 磁盘空间不足 (Disk Full during Write): 在写入数据时，磁盘空间耗尽。这将导致写入操作失败。
▮▮▮▮ⓒ I/O 错误 (I/O Error): 硬件故障、文件系统损坏或其他底层 I/O 问题可能导致读写操作失败。
▮▮▮▮ⓓ 文件损坏 (File Corruption): 尝试读取已损坏的文件，可能导致数据读取错误或程序崩溃。
▮▮▮▮ⓔ 网络文件系统错误 (Network File System Errors): 在使用网络文件系统（例如 NFS, SMB）时，网络连接问题、服务器故障等可能导致读写操作失败。
▮▮▮▮ⓕ 格式错误 (Format Error during Read/Write): 在进行格式化读写（例如使用 >> 或 << 运算符）时，输入数据的格式与期望的格式不符，可能导致读取或写入失败。
② 处理文件读写异常的方法:
与文件打开类似，文件流的读写操作（如 getline(), read(), write(), >>, << 等）在遇到错误时，也会设置内部错误标志位，并可以通过配置抛出 std::ios_base::failure 异常。
1
#include <iostream>
2
#include <fstream>
3
#include <string>
4
#include <stdexcept>
5
6
int main() {
7
std::string filename = "example.txt";
8
std::ofstream outputFile(filename);
9
10
// 配置 outputFile 在 failbit 和 badbit 置位时抛出异常
11
outputFile.exceptions(std::ofstream::failbit | std::ofstream::badbit);
12
13
try {
14
if (!outputFile.is_open()) {
15
throw std::runtime_error("Failed to open output file: " + filename);
16
}
17
18
outputFile << "This is line 1." << std::endl;
19
outputFile << "This is line 2." << std::endl;
20
// 假设在写入过程中磁盘空间耗尽，或者发生其他 I/O 错误
21
22
outputFile.close(); // RAII 会处理关闭，但显式关闭是好习惯
23
24
std::ifstream inputFile(filename);
25
inputFile.exceptions(std::ifstream::failbit | std::ifstream::badbit);
26
if (!inputFile.is_open()) {
27
throw std::runtime_error("Failed to open input file for reading: " + filename);
28
}
29
30
std::string line;
31
while (std::getline(inputFile, line)) {
32
std::cout << "Read line: " << line << std::endl;
33
// 假设在读取过程中文件损坏，或者发生其他 I/O 错误
34
}
35
inputFile.close();
36
37
} catch (const std::ios_base::failure& e) {
38
std::cerr << "I/O exception during file operation: " << e.what() << std::endl;
39
if (e.bad()) {
40
std::cerr << " Stream is in a bad state." << std::endl;
41
} else if (e.fail()) {
42
std::cerr << " Logical I/O operation failure." << std::endl;
43
}
44
} catch (const std::runtime_error& e) {
45
std::cerr << "Runtime error: " << e.what() << std::endl;
46
} catch (...) {
47
std::cerr << "Unknown exception caught during file operation." << std::endl;
48
}
49
50
return 0;
51
}
在这个例子中，我们演示了文件写入和读取操作，并配置了 outputFile 和 inputFile 在 failbit 或 badbit 置位时抛出异常。在 try 块中，我们执行写入和读取操作。如果在写入或读取过程中发生任何 I/O 错误（例如磁盘空间不足、文件损坏等），配置的异常标志位会触发 std::ios_base::failure 异常的抛出。catch 块部分与文件打开异常处理类似，捕获 std::ios_base::failure 异常并进行处理。
对于读取超出文件末尾的情况，getline() 等函数通常不会抛出异常，而是设置 eofbit。 eofbit 默认不会触发异常，但如果我们在 exceptions() 中包含了 eofbit，则在到达文件末尾时也会抛出异常。然而，通常情况下，到达文件末尾被视为正常的循环结束条件，而不是异常。程序应该通过检查流的状态（例如使用 inputFile.eof()）来判断是否到达文件末尾，并正常结束读取循环。
③ 最佳实践:
⚝ 细致的错误检查: 除了配置异常抛出，还应该在关键的读写操作后检查流的状态（例如使用 fail(), bad(), eof()），以便及时发现和处理错误。
⚝ 资源管理: 确保在文件操作完成后，及时关闭文件流，释放资源。RAII 原则在这里同样适用，文件流对象的析构函数会自动处理文件关闭。
⚝ 异常安全的代码: 在进行复杂的文件操作时，需要考虑异常安全，确保即使在异常发生时，程序也能保持在一致的状态，避免资源泄漏或数据损坏。例如，在更新文件内容时，可以先将新内容写入临时文件，成功后再替换原文件，以实现强异常安全保证。
⚝ 用户友好的错误信息: 当捕获到文件读写异常时，提供用户友好的错误信息，帮助用户理解问题并采取相应的措施。例如，提示用户检查磁盘空间、文件权限等。
通过综合运用异常处理和 RAII 等技术，我们可以编写出健壮、可靠的文件读写程序，有效地处理各种异常情况，保证数据的安全和程序的正常运行。
8.1.3 文件关闭与资源清理 (File Closing and Resource Cleanup)
文件操作完成后，务必进行文件关闭和资源清理。未正确关闭文件可能导致数据丢失、文件损坏、资源泄漏等问题。尤其是在异常处理的上下文中，确保资源清理的异常安全性 (Exception Safety) 至关重要。
① 文件关闭的重要性:
⚝ 数据刷新 (Data Flushing): 对于输出文件流（std::ofstream, std::fstream 以输出模式打开），数据通常会先缓存在内存缓冲区中。文件关闭操作会强制将缓冲区中的数据刷新到磁盘，确保数据完全写入文件。如果程序在数据刷新前崩溃或异常终止，缓冲区中的数据可能丢失。
⚝ 释放系统资源 (Releasing System Resources): 打开文件会占用系统资源，例如文件句柄 (File Handle)。文件句柄是操作系统用于跟踪打开文件的内部数据结构。系统能同时打开的文件句柄数量是有限的。如果不及时关闭文件，可能会耗尽文件句柄资源，导致后续的文件打开操作失败。
⚝ 文件锁定 (File Locking): 某些文件操作可能会对文件进行锁定，防止其他程序或进程同时访问或修改文件。文件关闭操作会释放文件锁，使其他程序可以访问该文件。
⚝ 避免文件损坏 (Preventing File Corruption): 不正确的文件关闭，尤其是在写入操作过程中，可能导致文件内容不完整或损坏。
② 资源清理的关键:
除了文件句柄，文件操作还可能涉及其他资源，例如内存缓冲区、网络连接等。资源清理的目标是释放所有程序占用的、不再需要的资源，防止资源泄漏。资源泄漏会逐渐消耗系统资源，导致程序性能下降，甚至系统崩溃。
③ 使用 RAII 确保异常安全的文件关闭与资源清理:
C++ 中的文件流对象（std::ifstream, std::ofstream, std::fstream）已经实现了 RAII 惯用法。文件流对象的析构函数会自动关闭文件。这意味着，无论程序正常执行结束，还是由于异常而提前退出作用域，文件流对象的析构函数都会被调用，文件都会被正确关闭。
1
#include <iostream>
2
#include <fstream>
3
#include <stdexcept>
4
5
void process_file(const std::string& filename) {
6
std::ifstream inputFile(filename); // RAII: 文件打开
7
8
if (!inputFile.is_open()) {
9
throw std::runtime_error("Failed to open file: " + filename);
10
}
11
12
std::string line;
13
while (std::getline(inputFile, line)) {
14
// 处理文件内容
15
std::cout << line << std::endl;
16
// ... 可能会抛出异常的代码 ...
17
if (line == "error") {
18
throw std::runtime_error("Simulated error during processing");
19
}
20
}
21
// inputFile 超出作用域，析构函数自动关闭文件 (RAII: 文件关闭)
22
}
23
24
int main() {
25
try {
26
process_file("example.txt");
27
} catch (const std::runtime_error& e) {
28
std::cerr << "Exception caught: " << e.what() << std::endl;
29
}
30
31
return 0;
32
}
在这个例子中，inputFile 是一个局部变量，在 process_file 函数开始时创建，函数结束时销毁。即使在 while 循环中抛出了 std::runtime_error 异常，导致函数提前退出，inputFile 对象仍然会被销毁，其析构函数会被调用，从而保证文件被正确关闭。
④ 显式关闭文件流 (Explicitly Closing File Streams):
虽然 RAII 提供了自动资源管理，显式调用 close() 方法仍然是一个好的编程习惯。显式关闭可以使代码意图更清晰，并且在某些复杂场景下，可以更精确地控制文件关闭的时机。例如，在需要立即刷新缓冲区并释放文件锁的情况下，显式调用 close() 可以提供更直接的控制。
1
#include <iostream>
2
#include <fstream>
3
#include <stdexcept>
4
5
void process_file_explicit_close(const std::string& filename) {
6
std::ifstream inputFile; // 先声明，不立即打开
7
try {
8
inputFile.open(filename); // 显式打开文件
9
if (!inputFile.is_open()) {
10
throw std::runtime_error("Failed to open file: " + filename);
11
}
12
13
std::string line;
14
while (std::getline(inputFile, line)) {
15
// 处理文件内容
16
std::cout << line << std::endl;
17
// ... 可能会抛出异常的代码 ...
18
if (line == "error") {
19
throw std::runtime_error("Simulated error during processing");
20
}
21
}
22
inputFile.close(); // 显式关闭文件
23
// ... 其他可能需要在文件关闭后执行的代码 ...
24
25
} catch (...) {
26
if (inputFile.is_open()) { // 确保在异常情况下也尝试关闭文件
27
inputFile.close(); // 显式关闭文件 (在 catch 块中)
28
}
29
throw; // 重新抛出异常，让外层处理
30
}
31
// 函数正常退出时，inputFile 对象销毁，析构函数也会被调用，但此时文件已经显式关闭，析构函数关闭操作是安全的 (no-op)
32
}
在这个例子中，我们首先声明了 inputFile 对象，但没有立即打开文件。在 try 块中使用 inputFile.open(filename); 显式打开文件。在正常处理完成后，使用 inputFile.close(); 显式关闭文件。在 catch 块中，我们首先检查文件是否已经打开 (inputFile.is_open())，如果是，则尝试显式关闭文件 (inputFile.close();)。 这样做可以双重保障文件关闭，即使在异常情况下，也能尽力确保文件被关闭。
⑤ 总结:
文件关闭和资源清理是文件操作中不可或缺的环节。RAII 机制为文件流提供了自动的异常安全资源管理，但显式调用 close() 方法仍然是一个好的编程习惯，可以增强代码的可读性和控制性。在编写文件操作代码时，务必牢记资源管理的重要性，确保即使在异常情况下，资源也能被正确释放，程序能够保持健壮性和可靠性。
8.1.4 案例：异常安全的文件读写类 (Case Study: Exception-Safe File Read/Write Class)
为了更好地展示如何在实际应用中结合异常处理和 RAII 来实现异常安全的文件操作，我们设计一个简单的异常安全的文件读写类 SecureFile。这个类封装了文件的打开、写入、读取和关闭操作，并确保在各种异常情况下，文件资源得到正确管理。
① SecureFile 类的设计:
SecureFile 类将主要包含以下功能：
⚝ 构造函数 (Constructor): 接受文件名和打开模式 (读/写模式)，打开文件，并在打开失败时抛出异常。
⚝ 析构函数 (Destructor): 自动关闭文件，释放资源。
⚝ 写入方法 (Write Methods): 提供写入字符串、字符等数据的方法，并在写入失败时抛出异常。
⚝ 读取方法 (Read Methods): 提供读取一行、读取指定长度数据等方法，并在读取失败时抛出异常。
⚝ 状态检查方法 (Status Check Methods): 提供检查文件是否打开、是否到达文件末尾等状态的方法。
② SecureFile 类的头文件 secure_file.h:
1
#ifndef SECURE_FILE_H
2
#define SECURE_FILE_H
3
4
#include <fstream>
5
#include <string>
6
#include <stdexcept>
7
#include <ios>
8
9
class SecureFile {
10
public:
11
enum OpenMode {
12
READ = 1,
13
WRITE = 2,
14
APPEND = 4,
15
READ_WRITE = READ | WRITE
16
};
17
18
private:
19
std::fstream fileStream;
20
std::string filename;
21
bool isOpen;
22
23
public:
24
// 构造函数：打开文件，失败抛出异常
25
SecureFile(const std::string& filename, OpenMode mode);
26
27
// 析构函数：自动关闭文件
28
~SecureFile();
29
30
// 写入字符串
31
void writeString(const std::string& data);
32
33
// 读取一行
34
std::string readLine();
35
36
// 检查文件是否打开
37
bool is_open() const { return isOpen; }
38
39
// 检查是否到达文件末尾
40
bool eof() const { return fileStream.eof(); }
41
42
private:
43
// 内部方法：检查文件流状态，抛出异常
44
void checkFileStreamStatus() const;
45
};
46
47
#endif // SECURE_FILE_H
③ SecureFile 类的实现文件 secure_file.cpp:
1
#include "secure_file.h"
2
3
#include <iostream> // for cerr in constructor
4
5
SecureFile::SecureFile(const std::string& filename, OpenMode mode)
6
: filename(filename), isOpen(false) {
7
std::ios_base::openmode openmode = std::ios::binary; // 默认二进制模式，可根据需要调整
8
if (mode & READ) openmode |= std::ios::in;
9
if (mode & WRITE) openmode |= std::ios::out;
10
if (mode & APPEND) openmode |= std::ios::app;
11
if (mode == READ_WRITE) openmode = std::ios::in | std::ios::out; // 读写模式需要特别设置
12
13
fileStream.exceptions(std::fstream::failbit | std::fstream::badbit); // 配置异常抛出
14
15
try {
16
fileStream.open(filename, openmode);
17
if (!fileStream.is_open()) { // 再次检查 is_open(), 以处理某些特殊情况
18
throw std::runtime_error("Failed to open file: " + filename);
19
}
20
isOpen = true;
21
} catch (const std::ios_base::failure& e) {
22
std::cerr << "File open exception: " << e.what() << std::endl; // 记录日志，可选
23
throw std::runtime_error("Error opening file: " + filename + ". " + e.what()); // 抛出 runtime_error
24
} catch (...) {
25
std::cerr << "Unknown exception during file open." << std::endl; // 记录未知异常
26
throw std::runtime_error("Unknown error occurred while opening file: " + filename);
27
}
28
}
29
30
SecureFile::~SecureFile() {
31
if (isOpen) {
32
try {
33
fileStream.close(); // 尝试关闭文件
34
isOpen = false;
35
} catch (const std::ios_base::failure& e) {
36
std::cerr << "Exception during file close: " << e.what() << std::endl; // 析构函数中异常通常只记录
37
// 析构函数中不应抛出异常，避免程序 terminate
38
} catch (...) {
39
std::cerr << "Unknown exception during file close." << std::endl;
40
}
41
}
42
}
43
44
void SecureFile::writeString(const std::string& data) {
45
if (!isOpen) {
46
throw std::runtime_error("File is not open for writing.");
47
}
48
try {
49
fileStream << data;
50
checkFileStreamStatus(); // 写入后检查状态
51
} catch (const std::ios_base::failure& e) {
52
throw std::runtime_error("Error writing to file: " + filename + ". " + e.what());
53
}
54
}
55
56
std::string SecureFile::readLine() {
57
if (!isOpen) {
58
throw std::runtime_error("File is not open for reading.");
59
}
60
std::string line;
61
try {
62
if (!std::getline(fileStream, line)) {
63
if (fileStream.eof()) { // 正常到达文件末尾，返回空字符串
64
return "";
65
}
66
checkFileStreamStatus(); // getline 操作失败，但不是 eof，检查状态并抛出异常
67
}
68
return line;
69
} catch (const std::ios_base::failure& e) {
70
throw std::runtime_error("Error reading from file: " + filename + ". " + e.what());
71
}
72
}
73
74
75
void SecureFile::checkFileStreamStatus() const {
76
if (fileStream.fail()) {
77
throw std::runtime_error("File stream operation failed (failbit set) on file: " + filename);
78
}
79
if (fileStream.bad()) {
80
throw std::runtime_error("File stream operation failed (badbit set) on file: " + filename);
81
}
82
// eofbit 通常不作为错误处理，而是在读取循环中作为结束条件检查
83
}
④ main.cpp 中使用 SecureFile 类:
1
#include "secure_file.h"
2
#include <iostream>
3
4
int main() {
5
try {
6
SecureFile writeFile("output.txt", SecureFile::WRITE);
7
writeFile.writeString("Hello, Secure File!\n");
8
writeFile.writeString("This is a second line.\n");
9
// writeFile 在这里超出作用域，析构函数自动关闭文件
10
11
SecureFile readFile("output.txt", SecureFile::READ);
12
std::string line;
13
while (!(line = readFile.readLine()).empty()) {
14
std::cout << "Read from file: " << line << std::endl;
15
}
16
// readFile 在这里超出作用域，析构函数自动关闭文件
17
18
SecureFile nonExistentFile("non_existent.txt", SecureFile::READ); // 预期抛出异常
19
20
} catch (const std::runtime_error& e) {
21
std::cerr << "Exception caught: " << e.what() << std::endl;
22
}
23
24
return 0;
25
}
在这个案例中，SecureFile 类通过 RAII 机制，在构造函数中打开文件，在析构函数中自动关闭文件，确保了资源管理的异常安全性。同时，类的方法内部配置了文件流的异常抛出，并在操作失败时抛出 std::runtime_error 类型的异常，使得文件操作的错误处理更加规范和集中。 main.cpp 演示了如何使用 SecureFile 类进行文件写入和读取，并使用 try-catch 块来捕获和处理可能发生的异常。
通过这个案例，我们展示了如何将异常处理和 RAII 结合起来，设计出异常安全、易于使用的文件操作类，提高程序的健壮性和可靠性。 这种设计思想可以推广到其他资源管理相关的类设计中。
8.2 网络编程中的异常处理 (Exception Handling in Network Programming)
8.2.1 网络连接异常 (Network Connection Exceptions)
网络编程中，建立网络连接是通信的首要步骤。然而，网络环境复杂多变，连接建立过程可能遇到各种异常情况。有效处理这些异常对于保证网络应用的健壮性和用户体验至关重要。
① 常见的网络连接异常场景:
▮▮▮▮ⓐ 连接超时 (Connection Timeout): 客户端尝试连接服务器，但在预定的时间内未能建立连接。这可能是由于网络延迟、服务器繁忙或服务器未响应等原因造成。
▮▮▮▮ⓑ 服务器拒绝连接 (Connection Refused): 服务器主动拒绝客户端的连接请求。这通常发生在服务器端口未开放、服务器程序未运行或服务器配置拒绝特定客户端连接时。
▮▮▮▮ⓒ 主机不可达 (Host Unreachable): 客户端无法找到目标服务器的主机。这可能是由于域名解析失败、网络路由问题或目标主机不存在等原因。
▮▮▮▮ⓓ 网络不可用 (Network Unreachable): 客户端所在的网络环境本身存在问题，例如网络接口未启用、没有网络连接或网络配置错误。
▮▮▮▮ⓔ 防火墙阻止 (Firewall Blocked): 客户端或服务器端的防火墙阻止了连接请求。
▮▮▮▮ⓕ 地址已被使用 (Address Already in Use): 尝试绑定套接字到已被其他程序占用的本地地址和端口。这通常发生在服务器程序启动时，如果之前的程序实例未正确关闭套接字。
② 处理网络连接异常的方法:
在 C++ 网络编程中，通常使用套接字 (Socket) API 进行网络通信。套接字操作（包括连接）可能会返回错误代码或抛出异常（取决于使用的库和 API 封装）。例如，在使用 boost::asio 或其他现代 C++ 网络库时，连接操作通常会抛出异常。即使在使用传统的 BSD 套接字 API，我们也应该将其封装在异常处理框架中，使其更易于管理和维护。
以下示例使用伪代码 (基于概念，具体实现依赖于所选网络库，例如 boost::asio):
1
#include <iostream>
2
#include <string>
3
#include <stdexcept>
4
// 假设的网络库头文件 (实际库可能不同)
5
#include <network_library.h>
6
7
void connect_to_server(const std::string& host, int port) {
8
Socket clientSocket; // 假设的套接字类
9
10
try {
11
clientSocket.connect(host, port); // 尝试连接服务器 (可能抛出异常)
12
std::cout << "Successfully connected to server: " << host << ":" << port << std::endl;
13
14
// ... 连接成功后的操作 ...
15
16
} catch (const ConnectionTimeoutException& e) { // 假设的连接超时异常
17
std::cerr << "Connection timeout to " << host << ":" << port << ": " << e.what() << std::endl;
18
// 处理连接超时，例如重试连接、提示用户稍后重试
19
throw; // 可选择重新抛出或在此处处理
20
} catch (const ConnectionRefusedException& e) { // 假设的连接被拒绝异常
21
std::cerr << "Connection refused by " << host << ":" << port << ": " << e.what() << std::endl;
22
// 处理连接被拒绝，例如检查服务器是否运行、端口是否正确
23
throw;
24
} catch (const HostUnreachableException& e) { // 假设的主机不可达异常
25
std::cerr << "Host unreachable: " << host << ": " << e.what() << std::endl;
26
// 处理主机不可达，例如检查主机名是否正确、网络连接是否正常
27
throw;
28
} catch (const NetworkException& e) { // 假设的网络通用异常基类
29
std::cerr << "Network error during connection to " << host << ":" << port << ": " << e.what() << std::endl;
30
// 处理其他网络错误，例如网络不可用、防火墙阻止等
31
throw;
32
} catch (const std::exception& e) { // 标准异常
33
std::cerr << "Standard exception during connection: " << e.what() << std::endl;
34
throw;
35
} catch (...) { // 其他未知异常
36
std::cerr << "Unknown exception during connection attempt to " << host << ":" << port << std::endl;
37
throw;
38
}
39
}
40
41
int main() {
42
try {
43
connect_to_server("example.com", 8080);
44
} catch (const std::exception& e) {
45
std::cerr << "Main function caught exception: " << e.what() << std::endl;
46
// 在主函数中统一处理连接异常
47
}
48
49
return 0;
50
}
在这个伪代码示例中，connect_to_server 函数尝试连接到指定的主机和端口。我们使用了 try-catch 块来捕获连接过程中可能发生的各种异常。
⚝ 具体的异常类型: 我们假设网络库会抛出具体的异常类型，例如 ConnectionTimeoutException, ConnectionRefusedException, HostUnreachableException 等，这些异常类型可以帮助我们更精确地诊断和处理连接问题。 实际的网络库可能会使用不同的异常类层次结构，需要查阅相关库的文档。
⚝ 网络通用异常: 我们还捕获了一个通用的网络异常基类 NetworkException，用于处理其他类型的网络错误。
⚝ 标准异常和未知异常: 最后，我们捕获 std::exception 和 catch(...) 来处理标准异常和未知异常，确保程序能够捕获所有可能的异常情况。
⚝ 重新抛出异常: 在每个 catch 块中，我们选择了 throw; 重新抛出异常。 这样做可以将异常传递给调用者（例如 main 函数）进行统一处理。 也可以在 catch 块中进行局部处理，例如记录日志、进行重试等，然后决定是否继续抛出异常。
③ 最佳实践:
⚝ 使用合适的超时设置: 在建立网络连接时，设置合理的超时时间非常重要。超时时间过短可能导致频繁的连接失败，超时时间过长会影响用户体验。
⚝ 重试机制 (Retry Mechanism): 对于某些类型的连接异常（例如连接超时、临时性网络故障），可以实现自动重试机制。重试机制应该包括退避策略 (Backoff Strategy)，避免在网络拥塞时进行过度的重试。
⚝ 用户反馈 (User Feedback): 当连接失败时，向用户提供清晰的错误提示信息，例如 "无法连接到服务器，请检查网络连接" 或 "服务器无响应，请稍后重试"。
⚝ 日志记录 (Logging): 详细记录连接异常的日志，包括时间、主机、端口、错误类型等信息，有助于问题诊断和排查。
⚝ 异常安全资源管理: 在网络编程中，套接字也是一种重要的资源。需要使用 RAII 等机制来确保套接字在异常情况下也能被正确关闭和释放，避免资源泄漏。
通过细致的异常处理和周全的设计，我们可以构建出健壮、可靠的网络应用程序，即使在复杂的网络环境中也能稳定运行。
8.2.2 数据传输异常 (Data Transmission Exceptions)
网络连接建立后，数据传输是网络通信的核心环节。然而，数据在网络传输过程中可能会遇到各种问题，导致传输失败或数据损坏。妥善处理数据传输异常是保证网络应用可靠性和数据完整性的关键。
① 常见的数据传输异常场景:
▮▮▮▮ⓐ 连接断开 (Connection Aborted/Reset/Closed): 在数据传输过程中，网络连接突然断开。这可能是由于网络故障、服务器崩溃、防火墙策略变化或对端主动关闭连接等原因造成。
▮▮▮▮ⓑ 传输超时 (Transmission Timeout): 在发送或接收数据时，超过预定的时间限制仍未完成操作。这可能是由于网络延迟、网络拥塞或对端处理缓慢等原因造成。
▮▮▮▮ⓒ 数据损坏 (Data Corruption): 数据在传输过程中发生损坏。虽然 TCP 协议本身具有校验机制，但在某些极端情况下（例如硬件故障），仍然可能出现数据损坏。
▮▮▮▮ⓓ 缓冲区溢出 (Buffer Overflow): 在接收数据时，接收缓冲区不足以容纳所有到达的数据。这可能导致数据丢失或程序崩溃。
▮▮▮▮ⓔ 协议错误 (Protocol Error): 通信双方在协议交互过程中出现错误，例如消息格式错误、状态机错误等。
▮▮▮▮ⓕ 资源耗尽 (Resource Exhaustion): 在进行大量数据传输时，系统资源（例如内存、CPU、网络带宽）可能耗尽，导致传输性能下降或失败。
② 处理数据传输异常的方法:
与连接异常类似，数据传输操作（例如发送和接收数据）也可能抛出异常或返回错误代码。我们需要使用 try-catch 块来捕获和处理这些异常。
以下示例仍然使用伪代码 (基于概念，具体实现依赖于网络库):
1
#include <iostream>
2
#include <string>
3
#include <stdexcept>
4
// 假设的网络库头文件
5
#include <network_library.h>
6
7
void send_and_receive_data(Socket& socket, const std::string& message) {
8
try {
9
socket.send(message); // 发送数据 (可能抛出异常)
10
std::cout << "Sent message: " << message << std::endl;
11
12
std::string receivedData = socket.receive(); // 接收数据 (可能抛出异常)
13
std::cout << "Received data: " << receivedData << std::endl;
14
15
// ... 数据传输成功后的操作 ...
16
17
} catch (const ConnectionAbortedException& e) { // 假设的连接断开异常
18
std::cerr << "Connection aborted: " << e.what() << std::endl;
19
// 处理连接断开，例如尝试重新连接、关闭套接字
20
throw;
21
} catch (const TransmissionTimeoutException& e) { // 假设的传输超时异常
22
std::cerr << "Transmission timeout: " << e.what() << std::endl;
23
// 处理传输超时，例如重发数据、调整超时时间
24
throw;
25
} catch (const DataCorruptionException& e) { // 假设的数据损坏异常
26
std::cerr << "Data corruption detected: " << e.what() << std::endl;
27
// 处理数据损坏，例如请求重传、关闭连接
28
throw;
29
} catch (const BufferOverflowException& e) { // 假设的缓冲区溢出异常
30
std::cerr << "Buffer overflow: " << e.what() << std::endl;
31
// 处理缓冲区溢出，例如增大缓冲区、调整接收速率
32
throw;
33
} catch (const ProtocolErrorException& e) { // 假设的协议错误异常
34
std::cerr << "Protocol error: " << e.what() << std::endl;
35
// 处理协议错误，例如检查协议实现、关闭连接
36
throw;
37
} catch (const NetworkException& e) { // 假设的网络通用异常
38
std::cerr << "Network error during data transmission: " << e.what() << std::endl;
39
throw;
40
} catch (const std::exception& e) { // 标准异常
41
std::cerr << "Standard exception during data transmission: " << e.what() << std::endl;
42
throw;
43
} catch (...) { // 未知异常
44
std::cerr << "Unknown exception during data transmission." << std::endl;
45
throw;
46
}
47
}
48
49
int main() {
50
Socket clientSocket;
51
try {
52
clientSocket.connect("example.com", 8080);
53
send_and_receive_data(clientSocket, "Hello Server!");
54
} catch (const std::exception& e) {
55
std::cerr << "Main function caught exception: " << e.what() << std::endl;
56
}
57
58
return 0;
59
}
在这个伪代码示例中，send_and_receive_data 函数演示了发送和接收数据的过程，并使用 try-catch 块捕获可能发生的数据传输异常。
⚝ 具体的异常类型: 我们假设网络库提供了针对数据传输的特定异常类型，例如 ConnectionAbortedException, TransmissionTimeoutException, DataCorruptionException, BufferOverflowException, ProtocolErrorException 等。 这些异常类型有助于我们根据具体的错误原因采取相应的处理措施。
⚝ 错误处理策略: 对于不同的数据传输异常，我们可以采取不同的处理策略。 例如，对于连接断开异常，可以尝试重新连接；对于传输超时异常，可以尝试重发数据；对于数据损坏异常，可以请求重传或关闭连接；对于缓冲区溢出异常，可以调整缓冲区大小或接收速率；对于协议错误，通常需要检查协议实现或关闭连接。
⚝ 保持连接状态: 在处理数据传输异常时，需要仔细考虑连接状态。 某些异常（例如连接断开）可能导致套接字失效，需要关闭并重新建立连接。 其他异常可能只是临时的，可以尝试恢复传输。
③ 最佳实践:
⚝ 合理的超时设置: 在数据传输操作中，设置合理的超时时间，防止程序长时间阻塞在等待数据上。
⚝ 错误重试与指数退避 (Exponential Backoff): 对于某些可恢复的传输错误（例如传输超时、临时性网络拥塞），可以实现错误重试机制，并结合指数退避策略，避免在网络状况不佳时进行过度的重试。
⚝ 数据校验与重传 (Data Checksum and Retransmission): 在某些对数据完整性要求极高的场景下，可以考虑在应用层实现数据校验机制（例如计算校验和）和数据重传机制，以弥补 TCP 协议在极端情况下的不足。
⚝ 流量控制与拥塞控制 (Flow Control and Congestion Control): 在设计网络应用时，需要考虑流量控制和拥塞控制，避免发送速率过快导致网络拥塞或接收端缓冲区溢出。 TCP 协议本身提供了流量控制和拥塞控制机制，但在应用层也可以进行一些优化，例如根据网络状况动态调整发送速率。
⚝ 心跳检测 (Heartbeat Detection): 对于长时间保持连接的应用，可以实现心跳检测机制，定期发送心跳包，检测连接是否仍然有效。 当检测到连接断开时，及时进行重连或资源清理。
⚝ 幂等性设计 (Idempotency Design): 在某些需要保证消息可靠性的应用场景下（例如分布式系统、支付系统），可以考虑设计幂等性的消息处理逻辑。 幂等性意味着同一条消息被重复处理多次，最终结果与处理一次的结果相同。 幂等性设计可以简化错误重试和消息去重逻辑。
通过全面考虑数据传输过程中可能出现的各种异常，并采取相应的处理策略和最佳实践，我们可以构建出高性能、高可靠性的网络应用程序，稳定地传输和处理数据。
8.2.3 套接字资源管理 (Socket Resource Management)
在网络编程中，套接字 (Socket) 是一种重要的系统资源。不正确的套接字资源管理可能导致资源泄漏，最终影响程序的性能和稳定性。尤其是在异常处理的上下文中，确保套接字资源的异常安全释放至关重要。
① 套接字资源的重要性:
⚝ 文件描述符 (File Descriptor) 泄漏: 在 Unix-like 系统中，套接字本质上是文件描述符。每个进程能打开的文件描述符数量是有限制的。 如果程序未能及时关闭不再使用的套接字，会导致文件描述符泄漏，最终耗尽文件描述符资源，使得新的套接字创建或文件打开操作失败。
⚝ 端口占用 (Port Binding): 服务器程序通常需要绑定到特定的端口才能监听客户端连接。 如果服务器程序异常退出，但套接字未正确关闭，可能导致端口仍然被占用，使得程序重启后无法重新绑定到该端口，直到操作系统释放该端口（通常需要一段时间）。
⚝ 系统资源消耗: 打开的套接字会占用一定的系统资源，例如内存、内核数据结构等。 大量未关闭的套接字会逐渐消耗系统资源，影响系统整体性能。
② RAII 与套接字资源管理:
RAII (Resource Acquisition Is Initialization) 惯用法是解决 C++ 中资源管理问题的有效方法。 我们可以将套接字的生命周期与 C++ 对象的生命周期绑定，利用对象的构造函数获取套接字资源，利用析构函数释放套接字资源。 这样可以确保套接字资源在任何情况下（包括异常发生时）都能被正确释放。
我们可以创建一个 SocketWrapper 类，封装套接字操作，并在其析构函数中关闭套接字。
以下示例使用伪代码 (基于概念，具体实现依赖于网络库):
1
#include <iostream>
2
#include <string>
3
#include <stdexcept>
4
// 假设的网络库头文件
5
#include <network_library.h>
6
7
class SocketWrapper {
8
private:
9
Socket socket; // 假设的套接字类
10
bool is_valid;
11
12
public:
13
// 构造函数：创建套接字
14
SocketWrapper() : is_valid(false) {
15
try {
16
socket = Socket(); // 创建套接字 (具体创建方式依赖于网络库)
17
is_valid = true;
18
} catch (...) {
19
is_valid = false;
20
throw; // 创建失败，抛出异常
21
}
22
}
23
24
// 析构函数：关闭套接字
25
~SocketWrapper() {
26
if (is_valid) {
27
try {
28
socket.close(); // 关闭套接字 (可能抛出异常，取决于网络库)
29
} catch (const std::exception& e) {
30
std::cerr << "Exception during socket close: " << e.what() << std::endl;
31
// 析构函数中异常通常只记录，不抛出
32
} catch (...) {
33
std::cerr << "Unknown exception during socket close." << std::endl;
34
}
35
}
36
}
37
38
// 禁止拷贝构造和拷贝赋值，只允许移动
39
SocketWrapper(const SocketWrapper&) = delete;
40
SocketWrapper& operator=(const SocketWrapper&) = delete;
41
SocketWrapper(SocketWrapper&&) noexcept = default;
42
SocketWrapper& operator=(SocketWrapper&&) noexcept = default;
43
44
45
// 其他套接字操作方法，例如 connect, send, receive 等，转发到内部 socket 对象
46
void connect(const std::string& host, int port) {
47
if (!is_valid) throw std::runtime_error("SocketWrapper is not valid.");
48
socket.connect(host, port); // 可能抛出连接异常
49
}
50
51
void send(const std::string& data) {
52
if (!is_valid) throw std::runtime_error("SocketWrapper is not valid.");
53
socket.send(data); // 可能抛出发送异常
54
}
55
56
std::string receive() {
57
if (!is_valid) throw std::runtime_error("SocketWrapper is not valid.");
58
return socket.receive(); // 可能抛出接收异常
59
}
60
61
// ... 其他方法 ...
62
};
63
64
void use_socket() {
65
SocketWrapper clientSocket; // RAII: SocketWrapper 对象创建，构造函数获取套接字资源
66
try {
67
clientSocket.connect("example.com", 8080);
68
clientSocket.send("Hello Server from RAII!");
69
std::string response = clientSocket.receive();
70
std::cout << "Received response: " << response << std::endl;
71
// ... 使用套接字进行通信 ...
72
73
} catch (const std::exception& e) {
74
std::cerr << "Exception caught in use_socket: " << e.what() << std::endl;
75
// 处理异常
76
throw; // 可选择重新抛出或在此处处理
77
}
78
// clientSocket 对象超出作用域，析构函数自动关闭套接字，释放资源 (RAII: 套接字资源释放)
79
}
80
81
int main() {
82
try {
83
use_socket();
84
} catch (const std::exception& e) {
85
std::cerr << "Main function caught exception: " << e.what() << std::endl;
86
}
87
88
return 0;
89
}
在这个伪代码示例中，SocketWrapper 类封装了套接字，并在其析构函数 ~SocketWrapper() 中调用 socket.close() 关闭套接字。 无论 use_socket() 函数正常结束还是抛出异常，clientSocket 对象超出作用域时，其析构函数都会被调用，从而保证套接字资源被正确释放。
⚝ 构造函数中的资源获取: SocketWrapper 的构造函数负责创建套接字。 如果套接字创建失败，构造函数应该抛出异常，防止对象创建成功但资源未获取的情况。
⚝ 析构函数中的资源释放: 析构函数负责关闭套接字。 析构函数内部的异常处理需要特别注意，通常只记录错误信息，不应该抛出异常，避免在栈展开 (Stack Unwinding) 过程中导致程序 terminate。
⚝ 禁用拷贝操作，允许移动操作: SocketWrapper 禁用了拷贝构造函数和拷贝赋值运算符，因为套接字资源通常是独占的，不适合进行浅拷贝。 允许移动构造函数和移动赋值运算符，可以支持在函数之间传递 SocketWrapper 对象。
⚝ 转发套接字操作: SocketWrapper 类可以提供 connect, send, receive 等方法，将这些操作转发到内部的 socket 对象。 这样可以保持用户使用套接字的方式与原始套接字 API 类似，同时享受到 RAII 带来的资源管理便利。
③ 最佳实践:
⚝ 始终使用 RAII 管理套接字: 对于所有套接字资源，都应该使用 RAII 机制进行管理，确保资源在任何情况下都能被正确释放。 可以自定义 SocketWrapper 类，或者使用网络库提供的 RAII 封装类（如果库提供了）。
⚝ 避免裸套接字指针: 尽量避免直接使用裸套接字指针，因为裸指针容易导致资源管理错误。 优先使用智能指针或 RAII 封装类来管理套接字资源。
⚝ 异常安全的代码: 在进行套接字操作的代码中，要充分考虑异常安全，确保即使在异常发生时，程序也能保持资源管理的正确性。
⚝ 资源泄漏检测: 在开发和测试阶段，可以使用资源泄漏检测工具（例如 Valgrind）来检查程序是否存在套接字资源泄漏问题。
通过采用 RAII 机制和遵循最佳实践，我们可以有效地管理套接字资源，避免资源泄漏，提高网络应用程序的稳定性和可靠性。
8.2.4 案例：异常安全的网络客户端 (Case Study: Exception-Safe Network Client)
为了进一步展示如何在实际网络编程中应用异常处理和 RAII，我们设计一个简单的异常安全的网络客户端类 SecureClient。 这个类封装了网络客户端的连接、发送数据、接收数据和断开连接等操作，并使用 SocketWrapper 类来管理套接字资源，确保异常安全。
① SecureClient 类的设计:
SecureClient 类将包含以下功能：
⚝ 构造函数 (Constructor): 可以接受服务器主机名和端口号，但不立即连接。
⚝ 连接方法 (Connect Method): 建立与服务器的连接，并在连接失败时抛出异常。 内部使用 SocketWrapper 管理套接字。
⚝ 发送方法 (Send Method): 发送数据到服务器，并在发送失败时抛出异常。
⚝ 接收方法 (Receive Method): 从服务器接收数据，并在接收失败时抛出异常。
⚝ 断开连接方法 (Disconnect Method): 主动断开与服务器的连接。 虽然 SocketWrapper 的析构函数会自动关闭套接字，显式的断开连接方法可以提供更清晰的控制。
② SecureClient 类的头文件 secure_client.h:
1
#ifndef SECURE_CLIENT_H
2
#define SECURE_CLIENT_H
3
4
#include <string>
5
#include <stdexcept>
6
#include "socket_wrapper.h" // 假设 SocketWrapper 类定义在 socket_wrapper.h 中
7
8
class SecureClient {
9
private:
10
std::string serverHost;
11
int serverPort;
12
SocketWrapper clientSocket; // 使用 SocketWrapper 管理套接字
13
bool isConnected;
14
15
public:
16
// 构造函数
17
SecureClient(const std::string& host, int port)
18
: serverHost(host), serverPort(port), isConnected(false) {}
19
20
// 连接到服务器
21
void connect();
22
23
// 发送数据
24
void sendData(const std::string& data);
25
26
// 接收数据
27
std::string receiveData();
28
29
// 断开连接
30
void disconnect();
31
32
// 检查是否已连接
33
bool is_connected() const { return isConnected; }
34
};
35
36
#endif // SECURE_CLIENT_H
③ SecureClient 类的实现文件 secure_client.cpp:
1
#include "secure_client.h"
2
#include <iostream>
3
4
void SecureClient::connect() {
5
if (isConnected) {
6
throw std::runtime_error("Already connected to server.");
7
}
8
try {
9
clientSocket.connect(serverHost, serverPort); // 使用 SocketWrapper 的 connect 方法
10
isConnected = true;
11
std::cout << "Connected to server: " << serverHost << ":" << serverPort << std::endl;
12
} catch (const std::exception& e) {
13
isConnected = false;
14
throw std::runtime_error("Failed to connect to server " + serverHost + ":" + std::to_string(serverPort) + ". " + e.what());
15
}
16
}
17
18
void SecureClient::sendData(const std::string& data) {
19
if (!isConnected) {
20
throw std::runtime_error("Not connected to server. Call connect() first.");
21
}
22
try {
23
clientSocket.send(data); // 使用 SocketWrapper 的 send 方法
24
std::cout << "Sent data: " << data << std::endl;
25
} catch (const std::exception& e) {
26
throw std::runtime_error("Failed to send data to server. " + e.what());
27
}
28
}
29
30
std::string SecureClient::receiveData() {
31
if (!isConnected) {
32
throw std::runtime_error("Not connected to server. Call connect() first.");
33
}
34
try {
35
std::string data = clientSocket.receive(); // 使用 SocketWrapper 的 receive 方法
36
std::cout << "Received data: " << data << std::endl;
37
return data;
38
} catch (const std::exception& e) {
39
throw std::runtime_error("Failed to receive data from server. " + e.what());
40
}
41
}
42
43
void SecureClient::disconnect() {
44
if (isConnected) {
45
isConnected = false; // 先标记为未连接
46
// SocketWrapper 对象 clientSocket 超出作用域，其析构函数会自动关闭套接字
47
std::cout << "Disconnected from server: " << serverHost << ":" << serverPort << std::endl;
48
} else {
49
std::cout << "Already disconnected or not connected." << std::endl;
50
}
51
}
52
53
// SecureClient 对象的析构函数不需要显式关闭套接字，因为 SocketWrapper 已经处理了
④ main.cpp 中使用 SecureClient 类:
1
#include "secure_client.h"
2
#include <iostream>
3
4
int main() {
5
SecureClient client("localhost", 8080); // 创建 SecureClient 对象
6
7
try {
8
client.connect(); // 连接到服务器
9
client.sendData("Hello Server from SecureClient!"); // 发送数据
10
std::string response = client.receiveData(); // 接收数据
11
std::cout << "Server response: " << response << std::endl;
12
client.disconnect(); // 断开连接 (可选，SocketWrapper 析构函数也会处理)
13
14
// 尝试连接到不存在的服务器，预期抛出异常
15
SecureClient badClient("non_existent_host", 12345);
16
badClient.connect(); // 预期抛出连接异常
17
18
} catch (const std::runtime_error& e) {
19
std::cerr << "Exception caught: " << e.what() << std::endl;
20
}
21
22
return 0;
23
}
在这个案例中，SecureClient 类使用了 SocketWrapper 类来管理套接字资源，实现了 RAII。 SecureClient 的 connect, sendData, receiveData 等方法都使用了异常处理，在操作失败时抛出 std::runtime_error 类型的异常。 main.cpp 演示了如何使用 SecureClient 类进行网络通信，并使用 try-catch 块来捕获和处理可能发生的异常。 即使在 main 函数的 try 块中发生了异常，client 对象和 badClient 对象超出作用域时，其内部的 SocketWrapper 对象也会被销毁，析构函数会被调用，从而保证套接字资源被正确释放，避免资源泄漏。
通过这个案例，我们展示了如何利用 RAII 和异常处理机制，构建出异常安全、易于使用的网络客户端类，提高网络应用程序的健壮性和可靠性。 这种设计模式可以推广到更复杂的网络应用开发中。
8.3 数据库操作中的异常处理 (Exception Handling in Database Operations)
8.3.1 数据库连接异常 (Database Connection Exceptions)
数据库操作通常始于建立与数据库服务器的连接。然而，数据库连接过程可能会遇到各种异常情况，例如数据库服务器不可用、连接参数错误、权限不足等。 妥善处理数据库连接异常是保证数据库应用可靠运行的基础。
① 常见的数据库连接异常场景:
▮▮▮▮ⓐ 数据库服务器不可用 (Database Server Unavailable): 数据库服务器宕机、网络故障或服务器进程未运行等原因导致客户端无法连接到数据库服务器。
▮▮▮▮ⓑ 连接参数错误 (Invalid Connection Parameters): 连接字符串、用户名、密码、主机名、端口号等连接参数配置错误，导致连接失败。
▮▮▮▮ⓒ 认证失败 (Authentication Failure): 提供的用户名或密码不正确，数据库服务器拒绝客户端的连接请求。
▮▮▮▮ⓓ 权限不足 (Insufficient Privileges): 用户账号没有足够的权限连接到指定的数据库或执行某些操作。
▮▮▮▮ⓔ 连接数超过限制 (Connection Limit Exceeded): 数据库服务器配置了最大连接数限制，当前连接数已达到上限，新的连接请求被拒绝。
▮▮▮▮ⓕ 网络问题 (Network Issues): 客户端与数据库服务器之间的网络连接存在问题，例如网络延迟、网络中断、路由错误等，导致连接失败。
▮▮▮▮ⓖ 数据库驱动程序错误 (Database Driver Error): 使用的数据库驱动程序本身存在错误或版本不兼容，导致连接失败。
② 处理数据库连接异常的方法:
在 C++ 数据库编程中，通常使用数据库客户端库（例如 libpq for PostgreSQL, mysqlclient for MySQL, SQLAPI++, ODBC, soci 等）来操作数据库。 这些库通常会提供异常处理机制或返回错误代码。 现代 C++ 数据库库倾向于使用异常来报告错误，使得错误处理更加清晰和统一。
以下示例使用伪代码 (基于概念，具体实现依赖于所选数据库库，例如假设使用一个名为 DatabaseLibrary 的库):
1
#include <iostream>
2
#include <string>
3
#include <stdexcept>
4
// 假设的数据库库头文件
5
#include <database_library.h>
6
7
void connect_to_database(const std::string& connectionString) {
8
DatabaseConnection connection; // 假设的数据库连接类
9
10
try {
11
connection.open(connectionString); // 尝试连接数据库 (可能抛出异常)
12
std::cout << "Successfully connected to database." << std::endl;
13
14
// ... 连接成功后的数据库操作 ...
15
16
} catch (const DatabaseServerUnavailableException& e) { // 假设的数据库服务器不可用异常
17
std::cerr << "Database server unavailable: " << e.what() << std::endl;
18
// 处理数据库服务器不可用，例如检查服务器状态、稍后重试连接
19
throw;
20
} catch (const InvalidConnectionParametersException& e) { // 假设的连接参数错误异常
21
std::cerr << "Invalid connection parameters: " << e.what() << std::endl;
22
// 处理连接参数错误，例如检查连接字符串、用户名、密码等
23
throw;
24
} catch (const AuthenticationFailedException& e) { // 假设的认证失败异常
25
std::cerr << "Authentication failed: " << e.what() << std::endl;
26
// 处理认证失败，例如检查用户名、密码是否正确、权限是否足够
27
throw;
28
} catch (const DatabaseConnectionException& e) { // 假设的数据库连接通用异常基类
29
std::cerr << "Database connection error: " << e.what() << std::endl;
30
// 处理其他数据库连接错误，例如连接数超过限制、网络问题、驱动程序错误等
31
throw;
32
} catch (const std::exception& e) { // 标准异常
33
std::cerr << "Standard exception during database connection: " << e.what() << std::endl;
34
throw;
35
} catch (...) { // 未知异常
36
std::cerr << "Unknown exception during database connection attempt." << std::endl;
37
throw;
38
}
39
}
40
41
int main() {
42
try {
43
connect_to_database("your_connection_string"); // 替换为实际的连接字符串
44
} catch (const std::exception& e) {
45
std::cerr << "Main function caught exception: " << e.what() << std::endl;
46
// 在主函数中统一处理数据库连接异常
47
}
48
49
return 0;
50
}
在这个伪代码示例中，connect_to_database 函数尝试连接到数据库。 我们使用 try-catch 块来捕获连接过程中可能发生的各种异常。
⚝ 具体的异常类型: 我们假设数据库库会抛出具体的异常类型，例如 DatabaseServerUnavailableException, InvalidConnectionParametersException, AuthenticationFailedException 等。 这些异常类型有助于我们更精确地诊断和处理连接问题。 实际的数据库库可能会使用不同的异常类层次结构，需要查阅相关库的文档。
⚝ 数据库通用异常: 我们还捕获了一个通用的数据库连接异常基类 DatabaseConnectionException，用于处理其他类型的数据库连接错误。
⚝ 错误处理策略: 对于不同的数据库连接异常，我们可以采取不同的处理策略。 例如，对于数据库服务器不可用异常，可以提示用户稍后重试或检查服务器状态； 对于连接参数错误异常，可以提示用户检查连接参数配置； 对于认证失败异常，可以提示用户检查用户名和密码是否正确。
⚝ 日志记录: 详细记录数据库连接异常的日志，包括时间、连接参数（敏感信息脱敏）、错误类型等信息，有助于问题诊断和排查。
⚝ 用户提示: 向用户提供友好的错误提示信息，例如 "无法连接到数据库，请检查数据库服务器是否运行" 或 "连接数据库失败，请检查连接参数"。
③ 最佳实践:
⚝ 连接池 (Connection Pooling): 对于需要频繁连接数据库的应用，使用连接池技术可以显著提高性能和资源利用率。 连接池维护一组预先建立的数据库连接，应用程序需要连接时从连接池获取连接，使用完毕后将连接返回连接池，而不是每次都重新建立和关闭连接。 连接池可以减少连接建立和关闭的开销，并限制数据库连接数，防止连接数超过限制。
⚝ 连接重试与退避 (Connection Retry and Backoff): 对于临时性的数据库连接失败（例如网络波动、服务器临时繁忙），可以实现连接重试机制。 重试机制应该包括退避策略，例如指数退避，避免在数据库服务器压力过大时进行过度的重试。
⚝ 连接超时 (Connection Timeout): 在建立数据库连接时，设置合理的连接超时时间，防止程序长时间阻塞在等待连接上。
⚝ 加密连接 (Encrypted Connection): 对于安全性要求高的应用，应该使用加密连接（例如 SSL/TLS）来保护数据库连接的安全性，防止敏感信息泄露。
⚝ 最小权限原则 (Principle of Least Privilege): 在配置数据库用户账号时，遵循最小权限原则，只授予用户账号完成其工作所需的最小权限。 避免使用高权限账号进行日常操作，降低安全风险。
⚝ 密码管理 (Password Management): 妥善管理数据库密码，避免将密码硬编码在程序中或明文存储在配置文件中。 可以使用环境变量、密钥管理系统或加密存储等方式来管理密码。
通过细致的异常处理和最佳实践，我们可以构建出健壮、安全的数据库应用程序，即使在复杂的数据库环境中也能稳定运行。
8.3.2 SQL 执行异常 (SQL Execution Exceptions)
数据库连接建立后，执行 SQL 语句是数据库操作的核心环节。然而，SQL 语句执行过程中可能会遇到各种异常情况，例如 SQL 语法错误、数据类型不匹配、违反约束、死锁等。 妥善处理 SQL 执行异常是保证数据一致性和应用稳定性的关键。
① 常见的 SQL 执行异常场景:
▮▮▮▮ⓐ SQL 语法错误 (SQL Syntax Error): SQL 语句本身存在语法错误，例如拼写错误、关键字使用错误、缺少必要的符号等，导致数据库服务器无法解析和执行 SQL 语句。
▮▮▮▮ⓑ 数据类型不匹配 (Data Type Mismatch): SQL 语句中使用了错误的数据类型，例如将字符串值插入到整数类型的列中，或者在比较操作中使用了不兼容的数据类型。
▮▮▮▮ⓒ 违反约束 (Constraint Violation): SQL 语句执行结果违反了数据库表定义的约束条件，例如唯一性约束、非空约束、外键约束、检查约束等。
▮▮▮▮ⓓ 死锁 (Deadlock): 多个事务同时请求锁定彼此占用的资源，导致相互等待，形成死锁。 数据库服务器通常会自动检测死锁，并选择回滚其中一个事务以解除死锁。
▮▮▮▮ⓔ 权限不足 (Insufficient Privileges): 当前数据库用户账号没有足够的权限执行指定的 SQL 语句，例如没有权限访问表、执行存储过程或执行管理操作。
▮▮▮▮ⓕ 资源不足 (Resource Exhaustion): 执行 SQL 语句需要消耗一定的数据库服务器资源，例如内存、CPU、磁盘 I/O 等。 如果数据库服务器资源不足，可能导致 SQL 执行失败。 例如，执行复杂的查询语句可能导致内存不足，或者执行大量的写入操作可能导致磁盘 I/O 瓶颈。
▮▮▮▮ⓖ 网络问题 (Network Issues): 在 SQL 语句执行过程中，客户端与数据库服务器之间的网络连接出现问题，例如网络延迟、网络中断等，可能导致 SQL 执行失败或超时。
② 处理 SQL 执行异常的方法:
数据库客户端库通常会在执行 SQL 语句失败时抛出异常或返回错误代码。 我们需要使用 try-catch 块来捕获和处理这些异常。
以下示例使用伪代码 (基于概念，具体实现依赖于数据库库):
1
#include <iostream>
2
#include <string>
3
#include <stdexcept>
4
// 假设的数据库库头文件
5
#include <database_library.h>
6
7
void execute_sql_query(DatabaseConnection& connection, const std::string& sql) {
8
try {
9
QueryResult result = connection.executeQuery(sql); // 执行 SQL 查询 (可能抛出异常)
10
std::cout << "SQL query executed successfully." << std::endl;
11
12
// ... 处理查询结果 ...
13
14
} catch (const SQLSyntaxErrorException& e) { // 假设的 SQL 语法错误异常
15
std::cerr << "SQL syntax error: " << e.what() << std::endl;
16
std::cerr << "SQL statement: " << sql << std::endl; // 打印错误的 SQL 语句，方便调试
17
// 处理 SQL 语法错误，例如检查 SQL 语句语法、提示用户修改
18
throw;
19
} catch (const DataTypeMismatchException& e) { // 假设的数据类型不匹配异常
20
std::cerr << "Data type mismatch error: " << e.what() << std::endl;
21
std::cerr << "SQL statement: " << sql << std::endl;
22
// 处理数据类型不匹配，例如检查数据类型、转换数据类型
23
throw;
24
} catch (const ConstraintViolationException& e) { // 假设的违反约束异常
25
std::cerr << "Constraint violation error: " << e.what() << std::endl;
26
std::cerr << "SQL statement: " << sql << std::endl;
27
// 处理违反约束，例如检查约束条件、修改数据
28
throw;
29
} catch (const DeadlockException& e) { // 假设的死锁异常
30
std::cerr << "Deadlock detected: " << e.what() << std::endl;
31
std::cerr << "SQL statement: " << sql << std::endl;
32
// 处理死锁，通常数据库服务器会自动处理死锁，客户端可以稍后重试事务
33
throw;
34
} catch (const InsufficientPrivilegesException& e) { // 假设的权限不足异常
35
std::cerr << "Insufficient privileges: " << e.what() << std::endl;
36
std::cerr << "SQL statement: " << sql << std::endl;
37
// 处理权限不足，例如检查用户权限、联系数据库管理员授权
38
throw;
39
} catch (const DatabaseException& e) { // 假设的数据库通用异常基类
40
std::cerr << "Database error during SQL execution: " << e.what() << std::endl;
41
std::cerr << "SQL statement: " << sql << std::endl;
42
// 处理其他数据库错误，例如资源不足、网络问题、数据库服务器错误等
43
throw;
44
} catch (const std::exception& e) { // 标准异常
45
std::cerr << "Standard exception during SQL execution: " << e.what() << std::endl;
46
std::cerr << "SQL statement: " << sql << std::endl;
47
throw;
48
} catch (...) { // 未知异常
49
std::cerr << "Unknown exception during SQL execution." << std::endl;
50
std::cerr << "SQL statement: " << sql << std::endl;
51
throw;
52
}
53
}
54
55
int main() {
56
DatabaseConnection connection;
57
try {
58
connection.open("your_connection_string"); // 连接数据库
59
execute_sql_query(connection, "SELECT * FROM users WHERE age > 'abc'"); // 预期抛出数据类型不匹配异常 (age 列是数字类型，但条件值是字符串)
60
} catch (const std::exception& e) {
61
std::cerr << "Main function caught exception: " << e.what() << std::endl;
62
// 在主函数中统一处理 SQL 执行异常
63
}
64
65
return 0;
66
}
在这个伪代码示例中，execute_sql_query 函数执行 SQL 查询。 我们使用 try-catch 块来捕获 SQL 执行过程中可能发生的各种异常。
⚝ 具体的异常类型: 我们假设数据库库会抛出具体的异常类型，例如 SQLSyntaxErrorException, DataTypeMismatchException, ConstraintViolationException, DeadlockException, InsufficientPrivilegesException 等。 这些异常类型有助于我们更精确地诊断和处理 SQL 执行问题。 实际的数据库库可能会使用不同的异常类层次结构，需要查阅相关库的文档。
⚝ 打印 SQL 语句: 在 catch 块中，我们打印了错误的 SQL 语句，这对于调试 SQL 执行错误非常有帮助。
⚝ 错误处理策略: 对于不同的 SQL 执行异常，我们可以采取不同的处理策略。 例如，对于 SQL 语法错误，可以检查 SQL 语句语法并修改； 对于数据类型不匹配异常，可以检查数据类型并进行转换； 对于违反约束异常，可以检查约束条件并修改数据； 对于死锁异常，通常数据库服务器会自动处理死锁，客户端可以稍后重试事务； 对于权限不足异常，可以检查用户权限并联系数据库管理员授权。
⚝ 事务回滚: 在事务处理中，如果 SQL 执行失败，通常需要回滚当前事务，保证数据一致性。 事务回滚将在下一节详细讨论。
③ 最佳实践:
⚝ 参数化查询 (Parameterized Queries) 或预编译语句 (Prepared Statements): 使用参数化查询或预编译语句可以有效地防止 SQL 注入攻击，并提高 SQL 执行效率。 参数化查询和预编译语句可以将 SQL 语句和参数值分开处理，避免将用户输入直接拼接到 SQL 语句中，从而消除 SQL 注入的风险。
⚝ 输入验证 (Input Validation): 在将用户输入作为 SQL 查询条件或数据值时，进行严格的输入验证，确保输入数据的格式和类型符合预期，防止数据类型不匹配和违反约束异常。
⚝ 最小权限原则: 在配置数据库用户账号时，遵循最小权限原则，只授予用户账号执行其工作所需的最小 SQL 操作权限。 避免使用高权限账号执行应用程序的 SQL 操作，降低安全风险。
⚝ SQL 语句优化 (SQL Optimization): 对于性能敏感的 SQL 查询语句，进行 SQL 语句优化，例如添加索引、优化查询条件、避免全表扫描等，提高 SQL 执行效率，减少数据库服务器资源消耗。
⚝ 错误日志记录: 详细记录 SQL 执行异常的日志，包括时间、SQL 语句、错误类型、错误信息等，有助于问题诊断和性能分析。
⚝ 监控与报警 (Monitoring and Alerting): 对数据库服务器进行监控，监控 SQL 执行性能、错误率、资源消耗等指标。 设置报警规则，当出现异常情况时及时报警，例如 SQL 执行错误率过高、数据库服务器资源消耗过高等。
通过周全的异常处理和最佳实践，我们可以编写出健壮、高效的数据库应用程序，有效地处理各种 SQL 执行错误，保证数据的完整性和应用的稳定运行。
8.3.3 事务处理与异常回滚 (Transaction Handling and Exception Rollback)
事务 (Transaction) 是数据库操作中的重要概念。事务保证了一系列数据库操作的 原子性 (Atomicity), 一致性 (Consistency), 隔离性 (Isolation), 持久性 (Durability), 即 ACID 特性。 在事务处理过程中，异常处理尤为重要。 当事务中的某个操作失败时，需要进行 事务回滚 (Transaction Rollback)，撤销之前在事务中已完成的所有操作，保证数据库数据的一致性。
① 事务的基本概念:
⚝ 原子性 (Atomicity): 事务是不可分割的最小操作单元。 事务中的所有操作要么全部成功提交 (Commit)，要么全部失败回滚 (Rollback)。 不存在部分成功部分失败的情况。
⚝ 一致性 (Consistency): 事务执行前后，数据库的数据必须保持一致性状态。 一致性是指数据库的完整性约束没有被破坏，例如数据类型约束、唯一性约束、外键约束等。
⚝ 隔离性 (Isolation): 多个事务并发执行时，每个事务都应该感觉不到其他事务的存在。 隔离性保证了并发事务之间互不干扰，避免数据竞争和数据不一致问题。 隔离级别 (Isolation Level) 定义了事务之间的隔离程度。 常见的隔离级别包括读未提交 (Read Uncommitted)、读已提交 (Read Committed)、可重复读 (Repeatable Read)、串行化 (Serializable)。
⚝ 持久性 (Durability): 事务一旦成功提交，其对数据库的修改就是永久性的，即使系统发生故障（例如断电、崩溃），已提交事务的数据也不会丢失。 持久性通常通过事务日志 (Transaction Log) 和数据备份 (Data Backup) 等机制来保证。
② 事务处理中的异常与回滚:
在事务处理过程中，任何操作都可能失败，例如 SQL 执行异常、违反约束、死锁、资源不足、网络问题等。 当事务中的某个操作失败时，为了保证事务的原子性和一致性，必须进行事务回滚。
⚝ 显式事务控制 (Explicit Transaction Control): 大多数数据库客户端库都提供了显式的事务控制 API，例如 beginTransaction(), commitTransaction(), rollbackTransaction() 等。 我们可以使用这些 API 来显式地控制事务的开始、提交和回滚。
以下示例使用伪代码 (基于概念，具体实现依赖于数据库库):
1
#include <iostream>
2
#include <string>
3
#include <stdexcept>
4
// 假设的数据库库头文件
5
#include <database_library.h>
6
7
void transfer_money(DatabaseConnection& connection, int fromAccountId, int toAccountId, double amount) {
8
Transaction transaction(connection); // RAII: 事务对象，构造函数开始事务，析构函数根据情况提交或回滚
9
10
try {
11
// 1. 从转出账户扣款
12
std::string sqlDebit = "UPDATE accounts SET balance = balance - " + std::to_string(amount) +
13
" WHERE account_id = " + std::to_string(fromAccountId);
14
connection.executeUpdate(sqlDebit); // 执行 SQL 更新 (可能抛出异常)
15
16
// 2. 向转入账户存款
17
std::string sqlCredit = "UPDATE accounts SET balance = balance + " + std::to_string(amount) +
18
" WHERE account_id = " + std::to_string(toAccountId);
19
connection.executeUpdate(sqlCredit); // 执行 SQL 更新 (可能抛出异常)
20
21
// 3. 记录交易日志
22
std::string sqlLog = "INSERT INTO transaction_logs (from_account_id, to_account_id, amount, transaction_time) "
23
"VALUES (" + std::to_string(fromAccountId) + ", " + std::to_string(toAccountId) + ", " +
24
std::to_string(amount) + ", NOW())";
25
connection.executeUpdate(sqlLog); // 执行 SQL 插入 (可能抛出异常)
26
27
transaction.commit(); // 所有操作成功，提交事务 (在 Transaction 析构函数中，根据状态判断是否提交)
28
std::cout << "Money transfer transaction committed successfully." << std::endl;
29
30
} catch (const std::exception& e) {
31
transaction.rollback(); // 任何操作失败，回滚事务 (在 Transaction 析构函数中，根据状态判断是否回滚)
32
std::cerr << "Transaction rolled back due to exception: " << e.what() << std::endl;
33
throw std::runtime_error("Money transfer transaction failed and rolled back. " + e.what()); // 重新抛出异常
34
}
35
// transaction 对象超出作用域，析构函数根据状态自动提交或回滚事务 (RAII: 事务管理)
36
}
37
38
39
class Transaction { // RAII 事务管理类
40
private:
41
DatabaseConnection& connection;
42
bool committed;
43
44
public:
45
Transaction(DatabaseConnection& conn) : connection(conn), committed(false) {
46
connection.beginTransaction(); // 构造函数开始事务
47
std::cout << "Transaction started." << std::endl;
48
}
49
50
~Transaction() {
51
if (!committed) {
52
connection.rollbackTransaction(); // 析构函数回滚事务 (如果未显式提交)
53
std::cout << "Transaction automatically rolled back." << std::endl;
54
} else {
55
std::cout << "Transaction already committed." << std::endl;
56
}
57
}
58
59
void commit() {
60
if (!committed) {
61
connection.commitTransaction(); // 显式提交事务
62
committed = true;
63
std::cout << "Transaction explicitly committed." << std::endl;
64
} else {
65
std::cout << "Transaction already committed, commit() call ignored." << std::endl;
66
}
67
}
68
69
void rollback() {
70
if (!committed) {
71
connection.rollbackTransaction(); // 显式回滚事务
72
committed = true; // 标记为已提交，防止析构函数再次回滚
73
std::cout << "Transaction explicitly rolled back." << std::endl;
74
} else {
75
std::cout << "Transaction already committed or rolled back, rollback() call ignored." << std::endl;
76
}
77
}
78
79
// 禁止拷贝构造和拷贝赋值，只允许移动
80
Transaction(const Transaction&) = delete;
81
Transaction& operator=(const Transaction&) = delete;
82
Transaction(Transaction&&) noexcept = default;
83
Transaction& operator=(Transaction&&) noexcept = default;
84
};
85
86
87
int main() {
88
DatabaseConnection connection;
89
try {
90
connection.open("your_connection_string"); // 连接数据库
91
transfer_money(connection, 123, 456, 100.0); // 执行转账事务
92
} catch (const std::runtime_error& e) {
93
std::cerr << "Main function caught exception: " << e.what() << std::endl;
94
// 在主函数中统一处理事务异常
95
}
96
97
return 0;
98
}
在这个伪代码示例中，transfer_money 函数模拟了银行转账操作，包含三个 SQL 操作：扣款、存款、记录日志。 我们使用 Transaction 类来管理事务。
⚝ RAII 事务管理类 Transaction: Transaction 类是一个 RAII 封装类，用于管理数据库事务的生命周期。 Transaction 对象的构造函数调用 connection.beginTransaction() 开始事务，析构函数根据事务是否已提交来决定是提交事务 (commitTransaction()) 还是回滚事务 (rollbackTransaction())。
⚝ try-catch 块中的事务操作: 在 transfer_money 函数的 try 块中，执行一系列 SQL 操作。 如果所有操作都成功完成，则调用 transaction.commit() 显式提交事务。 如果任何操作抛出异常，则在 catch 块中调用 transaction.rollback() 回滚事务。
⚝ 异常安全事务: 无论 transfer_money 函数正常结束还是抛出异常，transaction 对象超出作用域时，其析构函数都会被调用，从而保证事务要么被提交，要么被回滚，保证了事务的原子性和一致性。
⚝ 禁止拷贝操作，允许移动操作: Transaction 类也禁用了拷贝构造函数和拷贝赋值运算符，只允许移动操作，因为事务对象通常是不可拷贝的。
③ 最佳实践:
⚝ 始终使用 RAII 管理事务: 对于所有需要事务控制的数据库操作，都应该使用 RAII 机制来管理事务的生命周期，确保事务在任何情况下都能被正确提交或回滚。 可以自定义 Transaction 类，或者使用数据库库提供的 RAII 事务管理类（如果库提供了）。
⚝ 细粒度事务控制: 根据业务逻辑，合理划分事务的范围，尽量保持事务的短小精悍，避免长时间占用数据库资源，影响并发性能。
⚝ 幂等性操作: 在事务中执行的操作，尽量设计成幂等性的。 这样即使在事务提交过程中发生异常导致事务回滚后需要重试事务，也不会因为重复执行某些操作而导致数据错误。
⚝ 错误日志记录: 详细记录事务开始、提交、回滚以及事务执行过程中发生的异常日志，有助于问题诊断和审计。
⚝ 事务隔离级别选择: 根据应用的并发需求和数据一致性要求，选择合适的事务隔离级别。 较高的隔离级别可以提供更强的数据一致性保证，但会降低并发性能。 需要在数据一致性和并发性能之间进行权衡。
⚝ 死锁处理: 应用程序需要能够处理死锁异常。 通常数据库服务器会自动检测死锁并回滚其中一个事务，应用程序可以捕获死锁异常，并稍后重试事务。 避免长时间持有锁，减少死锁发生的概率。
⚝ 事务超时 (Transaction Timeout): 设置合理的事务超时时间，防止事务长时间运行，占用数据库资源。 当事务执行时间超过超时时间时，数据库服务器会自动回滚事务。
通过合理地使用事务处理和异常回滚机制，并遵循最佳实践，我们可以构建出数据一致性强、可靠性高的数据库应用程序，有效地处理各种数据库操作错误，保证数据的完整性和应用的稳定运行。
9. 现代 C++ 异常处理的新特性 (New Features in Modern C++ Exception Handling)
本章介绍 C++11 及以后版本中，关于异常处理的新特性和改进，例如 noexcept 的增强、std::exception_ptr（异常指针）、std::rethrow_exception() 等。这些新特性旨在提升代码的性能、灵活性和现代 C++ 编程范式的融合度。
9.1 noexcept 的增强 (Enhancements to noexcept)
noexcept 关键字在现代 C++ 中扮演着至关重要的角色，它不仅是对函数异常行为的声明，更是编译器进行性能优化的重要提示。本节回顾 noexcept 的基本概念，并深入探讨 C++17 中对 noexcept 的改进，特别是条件 noexcept 的应用范围扩展，以及 noexcept 与移动语义 (move semantics) 的深入结合。
9.1.1 条件 noexcept 的扩展应用 (Expanded Applications of Conditional noexcept)
C++17 显著扩展了条件 noexcept 的应用范围，使得编译器在更多场景下能够自动推导和优化代码。在 C++11 中，noexcept 说明符可以接受一个布尔表达式作为条件，即 noexcept(expression)。如果表达式 expression 在编译时求值为 true，则函数承诺不抛出异常；否则，函数可能抛出异常。C++17 的改进在于，条件 noexcept 能够更智能地根据函数体内的操作和调用的其他函数的 noexcept 属性进行推导。
例如，考虑以下代码：
1
#include <utility>
2
3
struct MayThrow {
4
MayThrow() {}
5
MayThrow(const MayThrow&) {}
6
MayThrow(MayThrow&&) noexcept(false) {} // 移动构造可能抛出异常
7
MayThrow& operator=(const MayThrow&) & { return *this; }
8
MayThrow& operator=(MayThrow&&) noexcept(false) & { return *this; } // 移动赋值可能抛出异常
9
~MayThrow() {}
10
};
11
12
struct NoThrow {
13
NoThrow() {}
14
NoThrow(const NoThrow&) noexcept {}
15
NoThrow(NoThrow&&) noexcept {} // 移动构造保证不抛出异常
16
NoThrow& operator=(const NoThrow&) & noexcept { return *this; }
17
NoThrow& operator=(NoThrow&&) & noexcept { return *this; } // 移动赋值保证不抛出异常
18
~NoThrow() noexcept {}
19
};
20
21
template <typename T>
22
void conditionalNoexceptMove(T t1, T t2) noexcept(std::is_nothrow_move_constructible_v<T> && std::is_nothrow_move_assignable_v<T>) {
23
T temp = std::move(t1); // 移动构造
24
t1 = std::move(t2); // 移动赋值
25
t2 = std::move(temp); // 移动赋值
26
}
27
28
int main() {
29
static_assert(noexcept(conditionalNoexceptMove(NoThrow{}, NoThrow{})), "NoThrow move should be noexcept");
30
static_assert(!noexcept(conditionalNoexceptMove(MayThrow{}, MayThrow{})), "MayThrow move should NOT be noexcept");
31
return 0;
32
}
在这个例子中，conditionalNoexceptMove 函数的 noexcept 说明符使用了 std::is_nothrow_move_constructible_v<T> 和 std::is_nothrow_move_assignable_v<T> 这两个类型特征 (type trait)。C++17 能够正确地根据模板参数 T 的移动构造函数 (move constructor) 和移动赋值运算符 (move assignment operator) 是否声明为 noexcept，来推断 conditionalNoexceptMove 函数自身是否为 noexcept。这使得 noexcept 的使用更加灵活和强大，尤其是在泛型编程 (generic programming) 中。
9.1.2 noexcept 与移动语义的深入结合 (Deeper Integration of noexcept and Move Semantics)
noexcept 与移动语义的结合是现代 C++ 性能优化的关键。移动语义旨在避免不必要的深拷贝 (deep copy)，提高资源转移的效率。然而，在某些情况下，例如 std::vector 的重新分配内存 (reallocation)，或者 std::sort 等算法的元素交换 (element swapping)，标准库容器和算法会优先选择移动操作，但前提是移动操作被保证不抛出异常。
如果移动构造函数或移动赋值运算符没有声明为 noexcept，标准库为了保证强异常安全保证 (strong exception safety guarantee)，可能会退而求其次选择拷贝操作 (copy operation)，即使移动操作在语义上是更优的选择。这是因为如果在移动过程中抛出异常，可能会导致原始对象处于不一致的状态，违反了强异常安全保证。
因此，强烈建议将移动构造函数、移动赋值运算符以及析构函数 (destructor) 声明为 noexcept，除非确实有合理的理由 (例如资源分配可能失败) 使得这些操作有可能抛出异常。声明 noexcept 后的移动操作不仅可以避免异常相关的运行时开销，更重要的是，它能够让编译器和标准库放心地使用移动语义进行优化。
例如，std::vector 的 push_back 操作，当容量不足需要重新分配内存时，如果元素类型的移动构造函数是 noexcept 的，std::vector 就可以使用移动语义将现有元素转移到新的内存区域，否则，为了异常安全，它将不得不使用拷贝语义。这在元素类型是大型对象或容器时，性能差异会非常显著。
总结来说，noexcept 的增强和与移动语义的深入结合，使得现代 C++ 能够编写出既安全又高效的代码。合理地使用 noexcept，特别是为移动操作和析构函数添加 noexcept 说明符，是提升 C++ 程序性能和异常安全性的重要手段。
9.2 异常指针：std::exception_ptr (Exception Pointers: std::exception_ptr)
std::exception_ptr（异常指针）是 C++11 引入的一个重要特性，它提供了一种在不同上下文之间传递异常信息的机制，尤其在异步编程和多线程 (multithreading) 环境中非常有用。std::exception_ptr 本身并不抛出或处理异常，它只是一个智能指针，用于指向某个异常对象的副本。通过 std::exception_ptr，我们可以安全地存储异常，并在稍后的时间或不同的线程中重新抛出 (rethrow) 它。
9.2.1 std::exception_ptr 的概念和用途 (Concept and Purpose of std::exception_ptr)
std::exception_ptr 的核心作用是捕获和存储异常，使得异常可以在原始抛出点之外被处理。它解决了在异步操作、回调函数 (callback function) 或跨线程边界传递异常的难题。在传统的同步异常处理中，异常的生命周期通常局限于 try-catch 块的作用域内。一旦 catch 块执行完毕，异常对象就会被销毁。但在异步或并发 (concurrent) 的场景下，我们可能需要在异常发生时先捕获它，稍后再在不同的上下文中进行处理。std::exception_ptr 正是为了满足这种需求而设计的。
std::exception_ptr 的主要用途包括：
① 异步操作中的异常传递: 在异步任务 (asynchronous task) 中，例如使用 std::async 或 std::future 时，子任务中抛出的异常无法直接传递到主线程的 catch 块中。std::exception_ptr 可以捕获子任务中的异常，并将其传递给主线程，主线程可以通过 std::future::get() 等方式获取并重新抛出异常。
② 回调函数中的异常处理: 在使用回调函数的场景中，如果回调函数内部抛出异常，调用者通常无法直接捕获。std::exception_ptr 可以用于在回调函数内部捕获异常，并将异常指针返回给调用者，由调用者决定如何处理。
③ 跨线程异常传递: 在多线程程序中，一个线程抛出的异常无法直接被另一个线程捕获。std::exception_ptr 可以用于在一个线程中捕获异常，并将异常指针传递给另一个线程，实现跨线程的异常传递和处理。
9.2.2 std::current_exception() 和 std::rethrow_exception() (std::current_exception() and std::rethrow_exception())
为了配合 std::exception_ptr 的使用，C++ 标准库提供了两个关键的函数：std::current_exception() 和 std::rethrow_exception()。
⚝ std::current_exception(): 这个函数用于捕获当前正在处理的异常，并返回一个指向该异常副本的 std::exception_ptr。如果在 catch 块外部调用 std::current_exception()，或者当前没有正在处理的异常，它将返回一个空的 std::exception_ptr。
⚝ std::rethrow_exception(std::exception_ptr p): 这个函数接受一个 std::exception_ptr 作为参数。如果传入的 std::exception_ptr 指向一个有效的异常对象，std::rethrow_exception() 将重新抛出该异常。如果传入的是空的 std::exception_ptr，std::rethrow_exception() 将不会抛出任何异常。
下面是一个简单的例子，演示了 std::current_exception() 和 std::rethrow_exception() 的用法：
1
#include <iostream>
2
#include <exception>
3
4
void process_data() {
5
throw std::runtime_error("Error during data processing");
6
}
7
8
int main() {
9
std::exception_ptr p;
10
try {
11
process_data();
12
} catch (...) {
13
p = std::current_exception(); // 捕获当前异常的异常指针
14
std::cerr << "Exception caught, will be re-thrown later." << std::endl;
15
}
16
17
if (p) {
18
std::cerr << "Re-throwing the exception:" << std::endl;
19
try {
20
std::rethrow_exception(p); // 重新抛出异常
21
} catch (const std::exception& e) {
22
std::cerr << "Caught exception again: " << e.what() << std::endl;
23
}
24
}
25
26
return 0;
27
}
在这个例子中，process_data() 函数抛出一个 std::runtime_error 异常。在 main() 函数的 try-catch 块中，我们使用 std::current_exception() 捕获了异常指针 p。随后，我们检查 p 是否有效，如果有效，就使用 std::rethrow_exception(p) 重新抛出异常，并在外层的 catch 块中再次捕获并处理。
9.2.3 std::make_exception_ptr() ( std::make_exception_ptr() )
除了 std::current_exception()，C++17 还引入了 std::make_exception_ptr<E>(E e) 模板函数，用于直接创建一个指向指定异常对象 e 的 std::exception_ptr。std::make_exception_ptr() 可以接受任何类型的异常对象作为参数，并返回一个指向该异常对象副本的 std::exception_ptr。
使用 std::make_exception_ptr() 的好处是可以在没有实际抛出异常的情况下，创建异常指针。这在某些需要手动创建和传递异常信息的场景下非常方便。
例如：
1
#include <iostream>
2
#include <exception>
3
4
std::exception_ptr create_exception_ptr() {
5
return std::make_exception_ptr(std::logic_error("人为制造的逻辑错误"));
6
}
7
8
int main() {
9
std::exception_ptr p = create_exception_ptr();
10
if (p) {
11
try {
12
std::rethrow_exception(p);
13
} catch (const std::exception& e) {
14
std::cerr << "Caught exception created by make_exception_ptr: " << e.what() << std::endl;
15
}
16
}
17
return 0;
18
}
在这个例子中，create_exception_ptr() 函数没有实际抛出异常，而是使用 std::make_exception_ptr() 创建了一个指向 std::logic_error 对象的异常指针并返回。main() 函数接收到这个异常指针后，可以使用 std::rethrow_exception() 重新抛出异常进行处理。
9.2.4 异步操作中的异常传递 (Exception Propagation in Asynchronous Operations)
std::exception_ptr 在异步操作中的异常传递方面发挥着关键作用。结合 std::future 和 std::async，我们可以实现异步任务的异常处理。当一个异步任务 (由 std::async 启动) 抛出异常时，该异常会被捕获并存储在与 std::async 返回的 std::future 对象关联的异常指针中。当我们在主线程中调用 std::future::get() 获取异步任务的结果时，如果异步任务中发生了异常，std::future::get() 会重新抛出存储在异常指针中的异常。
1
#include <iostream>
2
#include <future>
3
#include <stdexcept>
4
5
int asynchronous_task() {
6
throw std::runtime_error("Exception from asynchronous task");
7
return 42; // 这行代码不会被执行
8
}
9
10
int main() {
11
std::future<int> result_future = std::async(std::launch::async, asynchronous_task);
12
13
try {
14
int result = result_future.get(); // 获取异步任务结果，可能抛出异常
15
std::cout << "Result: " << result << std::endl; // 不会被执行
16
} catch (const std::exception& e) {
17
std::cerr << "Caught exception from asynchronous task: " << e.what() << std::endl;
18
}
19
20
return 0;
21
}
在这个例子中，asynchronous_task() 函数在异步线程中执行，并抛出一个 std::runtime_error 异常。std::async 返回的 result_future 对象会持有这个异常的异常指针。当 main() 函数调用 result_future.get() 时，由于异步任务中发生了异常，get() 函数会重新抛出该异常，从而在主线程的 catch 块中捕获并处理异步任务中发生的错误。
总结来说，std::exception_ptr、std::current_exception()、std::rethrow_exception() 和 std::make_exception_ptr() 一起构成了一套强大的异常处理机制，尤其适用于现代 C++ 的异步编程和并发编程，使得异常可以在不同的执行上下文之间安全可靠地传递和处理。
9.3 其他现代 C++ 异常处理特性 (Other Modern C++ Exception Handling Features)
除了 noexcept 的增强和 std::exception_ptr，现代 C++ 还引入了一些其他的与异常处理相关的特性，例如 std::terminate_handler（终止处理函数）、std::set_terminate()（设置终止处理函数）以及 std::unexpected_handler（意外处理函数）和 std::set_unexpected()（设置意外处理函数），尽管 std::unexpected_handler 和 std::set_unexpected() 已经被废弃。
9.3.1 std::terminate_handler 和 std::set_terminate() (std::terminate_handler and std::set_terminate())
std::terminate_handler 是一种类型别名 (type alias)，定义了终止处理函数的类型，通常是一个无参数、返回 void 的函数指针。std::set_terminate(std::terminate_handler f) 函数允许我们自定义程序在未捕获异常 (uncaught exception) 发生时的行为。
当程序中抛出了异常，但没有找到合适的 catch 块来处理它时，C++ 运行时环境会默认调用 std::terminate() 函数。std::terminate() 默认行为是调用 std::abort()，立即终止程序。通过 std::set_terminate()，我们可以注册一个自定义的终止处理函数，替换默认的 std::terminate() 行为。
自定义终止处理函数可以用于执行一些最后的清理工作，例如日志记录 (logging)、资源释放 (resource releasing) 或者生成崩溃报告 (crash report)，然后再终止程序。但需要注意的是，终止处理函数不应该尝试恢复程序执行，它的主要目的是在程序即将崩溃前执行一些必要的收尾工作。
1
#include <iostream>
2
#include <exception>
3
#include <cstdlib>
4
5
void my_terminate_handler() noexcept {
6
std::cerr << "Custom terminate handler called. Program will now terminate." << std::endl;
7
// 可以添加日志记录、资源释放等操作
8
std::abort(); // 最终仍然需要终止程序
9
}
10
11
void throw_uncaught_exception() {
12
throw std::runtime_error("Uncaught exception!");
13
}
14
15
int main() {
16
std::set_terminate(my_terminate_handler); // 设置自定义终止处理函数
17
18
try {
19
throw_uncaught_exception();
20
} catch (const std::exception& e) {
21
std::cerr << "Caught in main, but will re-throw to trigger terminate: " << e.what() << std::endl;
22
throw; // 重新抛出异常，使其变为未捕获异常
23
}
24
// 如果异常未被捕获，将调用 my_terminate_handler
25
return 0; // 不会被执行到
26
}
在这个例子中，我们使用 std::set_terminate(my_terminate_handler) 将自定义的 my_terminate_handler 函数注册为终止处理函数。当 throw_uncaught_exception() 抛出的异常在 main() 函数的 try-catch 块中被捕获后，我们又使用 throw; 重新抛出异常，使其变为未捕获异常。由于没有更外层的 catch 块来处理这个异常，程序最终会调用我们注册的 my_terminate_handler 函数，然后终止。
9.3.2 std::unexpected_handler 和 std::set_unexpected() [已废弃] (std::unexpected_handler and std::set_unexpected() [Deprecated])
std::unexpected_handler 和 std::set_unexpected() 是 C++98 标准中引入的，用于处理违反动态异常规范 (dynamic exception specification) 的情况。然而，动态异常规范本身在 C++11 中已经被废弃，因此 std::unexpected_handler 和 std::set_unexpected() 也随之被标记为废弃，并在 C++17 中正式移除。
在 C++11 之前，函数可以声明一个动态异常规范，例如 void foo() throw(int, std::bad_alloc);，表示 foo 函数最多可能抛出 int 或 std::bad_alloc 类型的异常。如果在运行时，foo 函数抛出了一个不在异常规范列表中的异常，C++ 运行时环境会调用 std::unexpected() 函数，而 std::unexpected() 默认行为是调用 std::terminate()。
std::set_unexpected(std::unexpected_handler f) 函数允许我们自定义 std::unexpected() 的行为，注册一个自定义的意外处理函数。但是，由于动态异常规范的缺陷和废弃，std::unexpected_handler 和 std::set_unexpected() 也失去了存在的意义，现代 C++ 编程中不再使用这些特性。
总结: 现代 C++ 异常处理的新特性主要集中在 noexcept 的增强和 std::exception_ptr 的引入，这些特性更好地支持了现代 C++ 的性能优化、异步编程和并发编程范式。而像 std::unexpected_handler 和 std::set_unexpected() 这样的旧特性已经被废弃，不应在现代 C++ 代码中使用。理解和掌握 noexcept 和 std::exception_ptr 是编写高效、安全、现代 C++ 程序的关键。
Appendix A: 附录 A：C++ 标准异常类层次结构 (Appendix A: C++ Standard Exception Class Hierarchy)
附录 A：C++ 标准异常类层次结构 (Appendix A: C++ Standard Exception Class Hierarchy)
本附录旨在通过图形化的方式 🗺️ 展示 C++ 标准异常类 (Standard Exception Classes) 的继承关系，以帮助读者更直观地理解和查阅 C++ 标准库提供的异常类体系。理解这些标准异常类及其组织结构，能够帮助开发者在程序设计中选择合适的异常类型，并更好地进行错误处理 (Error Handling)。
C++ 标准异常类层次结构主要根植于 std::exception 基类，并由此派生出各种表示不同类型错误的异常类。这种层次结构的设计，使得异常处理更加精细化和类型安全 (Type-safe)。
以下是 C++ 标准异常类层次结构的文本表示：
① std::exception
▮ ⚝ 描述了所有标准异常的基类 (Base class for all standard exceptions)。
▮ ▮ ① std::logic_error
▮ ▮ ▮ ⚝ 表示程序逻辑上的错误 (Errors in program logic)。
▮ ▮ ▮ ▮ ⓐ std::domain_error
▮ ▮ ▮ ▮ ▮ ⚝ 定义了数学定义域错误，例如给 sqrt() 函数传递负数 (Domain error, e.g., negative input to sqrt())。
▮ ▮ ▮ ▮ ⓑ std::invalid_argument
▮ ▮ ▮ ▮ ▮ ⚝ 表示无效参数，例如传递了不合法的函数参数 (Invalid function argument)。
▮ ▮ ▮ ▮ ⓒ std::length_error
▮ ▮ ▮ ▮ ▮ ⚝ 当试图创建一个超出最大允许长度的对象时抛出，例如 std::string 或 std::vector (Attempt to create an object exceeding maximum size)。
▮ ▮ ▮ ▮ ⓓ std::out_of_range
▮ ▮ ▮ ▮ ▮ ⚝ 表示访问越界，例如 std::vector::at() 访问超出范围的索引 (Out-of-range access, e.g., std::vector::at() with invalid index)。
▮ ▮ ▮ ▮ ⓔ std::future_error (C++11)
▮ ▮ ▮ ▮ ▮ ⚝ 与 std::future 和异步操作相关的错误 (Errors related to std::future and asynchronous operations)。
▮ ▮ ▮ ② std::runtime_error
▮ ▮ ▮ ⚝ 表示运行时错误，通常是程序运行时才能检测到的错误 (Errors detected during runtime)。
▮ ▮ ▮ ▮ ⓐ std::range_error
▮ ▮ ▮ ▮ ▮ ⚝ 表示计算结果超出有效范围，例如数值计算溢出 (Range error, e.g., numeric overflow)。
▮ ▮ ▮ ▮ ⓑ std::overflow_error
▮ ▮ ▮ ▮ ▮ ⚝ 算术溢出错误 (Arithmetic overflow error)。
▮ ▮ ▮ ▮ ⓒ std::underflow_error
▮ ▮ ▮ ▮ ▮ ⚝ 算术下溢错误 (Arithmetic underflow error)。
▮ ▮ ▮ ▮ ⓓ std::system_error (C++11)
▮ ▮ ▮ ▮ ▮ ⚝ 表示与操作系统相关的错误，通常与系统调用失败有关 (Low-level system errors)。
▮ ▮ ▮ ▮ ▮ ▮ ❶ std::ios_base::failure
▮ ▮ ▮ ▮ ▮ ▮ ▮ ⚝ 与 I/O 流操作相关的错误 (I/O stream operation failure)。
▮ ▮ ② std::bad_alloc
▮ ▮ ▮ ⚝ 当内存分配失败时抛出，例如 new 运算符分配内存失败 (Memory allocation failure, e.g., new operator failure)。
▮ ▮ ③ std::bad_cast
▮ ▮ ▮ ⚝ 当 dynamic_cast 尝试执行到引用的无效类型转换时抛出 (Invalid dynamic_cast to reference)。
▮ ▮ ④ std::bad_typeid
▮ ▮ ▮ ⚝ 当 typeid 运算符应用于 nullptr 解引用的多态类型时抛出 (Applied typeid operator to dereferenced null pointer of a polymorphic type)。
▮ ▮ ⑤ std::bad_function_call (C++11)
▮ ▮ ▮ ⚝ 当尝试调用空的 std::function 对象时抛出 (Attempt to call an empty std::function object)。
▮ ▮ ⑥ std::bad_variant_access (C++17)
▮ ▮ ▮ ⚝ 当尝试以错误类型访问 std::variant 对象时抛出 (Attempt to access std::variant object with wrong type)。
▮ ② std::nested_exception (C++11)
▮ ▮ ⚝ 用于支持嵌套异常，可以捕获并存储另一个异常 (Supports nested exceptions, can capture and store another exception)。
注意：
⚝ std::error_category, std::error_code, std::error_condition (C++11) 等与 <system_error> 相关的类，虽然也用于错误处理，但它们不直接继承自 std::exception，而是构成 C++ 错误报告机制的一部分，通常与 std::system_error 一起使用。
⚝ std::ios_base::failure 实际上是嵌套在 std::ios_base 类中的，但从异常继承关系的角度，可以看作是 std::system_error 的一种特定类型，因为它通常也反映了底层系统调用或 I/O 操作的失败。
这个层次结构旨在覆盖常见的错误类型，并为开发者提供一个清晰的框架来组织和处理程序中可能出现的各种异常情况。通过理解和利用这个标准异常类层次结构，可以编写出更加健壮和易于维护的 C++ 程序。
Appendix B: 常见异常处理陷阱与解决方案 (Appendix B: Common Exception Handling Pitfalls and Solutions)
本附录总结在 C++ 异常处理中常见的错误和陷阱，并提供相应的解决方案和最佳实践建议。
B.1 陷阱一：按值捕获异常 (Pitfall 1: Catching Exceptions by Value)
按值捕获异常会导致对象切割 (Object Slicing) 问题，丢失异常对象的派生类信息，并可能引发性能问题。这是 C++ 异常处理中最常见的陷阱之一。
B.1.1 问题描述：对象切割 (Problem Description: Object Slicing)
① 当你按值 (by value) 捕获异常时，catch 子句会创建一个被抛出异常对象的副本。
② 如果抛出的异常对象是派生类 (derived class) 的实例，而 catch 子句指定的是基类 (base class) 类型，则会发生对象切割。
③ 对象切割意味着只有基类部分 (base class part) 的数据会被复制到 catch 子句的异常对象中，派生类特有的数据和行为会丢失。
④ 这会导致你无法访问到异常对象的完整信息，尤其是在自定义异常类中添加了额外错误信息的情况下。
1
#include <iostream>
2
#include <stdexcept>
3
4
class CustomException : public std::runtime_error {
5
public:
6
CustomException(const std::string& message) : std::runtime_error(message), errorCode(123) {}
7
int getErrorCode() const { return errorCode; }
8
private:
9
int errorCode;
10
};
11
12
void throwException() {
13
throw CustomException("Something went wrong in CustomException.");
14
}
15
16
int main() {
17
try {
18
throwException();
19
} catch (std::runtime_error e) { // ⚠️ 按值捕获 (Catch by value)
20
std::cerr << "Caught runtime_error: " << e.what() << std::endl;
21
// 无法访问 errorCode, 因为对象被切割 (Cannot access errorCode due to object slicing)
22
}
23
return 0;
24
}
在这个例子中，CustomException 继承自 std::runtime_error 并添加了 errorCode 成员。当按值捕获 std::runtime_error 时，errorCode 信息丢失了。
B.1.2 解决方案：按引用或常量引用捕获 (Solution: Catch by Reference or Const Reference)
① 按引用捕获 (Catch by reference) 或 按常量引用捕获 (Catch by const reference) 可以避免对象切割。
② 使用引用捕获，catch 子句直接操作被抛出的原始异常对象，而不是其副本。
③ 这样可以保留异常对象的完整类型信息和数据，包括派生类特有的成员。
④ 推荐使用 按常量引用捕获 catch (const std::exception& e)，因为它既避免了对象切割，又防止在 catch 块中意外修改异常对象。
1
#include <iostream>
2
#include <stdexcept>
3
4
class CustomException : public std::runtime_error {
5
public:
6
CustomException(const std::string& message) : std::runtime_error(message), errorCode(123) {}
7
int getErrorCode() const { return errorCode; }
8
private:
9
int errorCode;
10
};
11
12
void throwException() {
13
throw CustomException("Something went wrong in CustomException.");
14
}
15
16
int main() {
17
try {
18
throwException();
19
} catch (const std::runtime_error& e) { // ✅ 按常量引用捕获 (Catch by const reference)
20
std::cerr << "Caught runtime_error: " << e.what() << std::endl;
21
const CustomException* customEx = dynamic_cast<const CustomException*>(&e);
22
if (customEx) {
23
std::cerr << "Error Code: " << customEx->getErrorCode() << std::endl; // 可以访问 errorCode (Can access errorCode)
24
}
25
}
26
return 0;
27
}
在这个修正后的例子中，我们使用 catch (const std::runtime_error& e) 按常量引用捕获异常。通过 dynamic_cast 可以安全地将 std::runtime_error& 转换为 CustomException*，并访问 errorCode。
B.2 陷阱二：过度宽泛的捕获 (catch(...)) (Pitfall 2: Overly Broad Catching (catch(...)))
使用省略号 catch(...) 可以捕获所有类型的异常，但这通常是一个反模式 (anti-pattern)，因为它会隐藏错误，使程序行为难以预测和调试。
B.2.1 问题描述：隐藏错误和调试困难 (Problem Description: Hiding Errors and Debugging Difficulty)
① catch(...) 会捕获任何类型的异常，包括你可能没有预料到或无法处理的异常。
② 这可能导致程序在遇到严重错误时仍然继续运行，但处于未定义状态 (undefined state)。
③ 隐藏了真正的错误信息，使得 调试 (debugging) 变得极其困难，因为你可能不知道程序究竟发生了什么错误。
④ 有时候 catch(...) 被错误地用于“吞噬” (swallow) 异常，阻止异常传播到更合适的处理程序，导致资源泄漏或其他问题。
1
#include <iostream>
2
#include <stdexcept>
3
4
void mightThrow() {
5
// 假设这里可能抛出各种类型的异常 (Assume various types of exceptions might be thrown here)
6
throw std::runtime_error("Unexpected error occurred.");
7
}
8
9
int main() {
10
try {
11
mightThrow();
12
} catch (...) { // ⚠️ 捕获所有异常 (Catch all exceptions)
13
std::cerr << "Something went wrong, but we don't know what..." << std::endl;
14
// 无法获取异常的具体信息 (Cannot get specific exception information)
15
// 可能的资源清理操作 (Potentially perform some resource cleanup)
16
}
17
// 程序继续执行，但可能处于不一致的状态 (Program continues, but might be in an inconsistent state)
18
return 0;
19
}
在这个例子中，catch(...) 捕获了 std::runtime_error 异常，但我们无法访问到 e.what() 或其他异常信息，错误被有效地隐藏了。
B.2.2 解决方案：捕获特定异常类型或重新抛出 (Solution: Catch Specific Exception Types or Re-throw)
① 优先捕获特定类型的异常 (Prefer catching specific exception types)，这样你可以针对不同类型的错误进行不同的处理。
② 只有当你确实需要捕获所有异常，并且有明确的处理策略 (e.g., 日志记录、资源清理后重新抛出) 时，才考虑使用 catch(...)。
③ 在 catch(...) 块中，通常应该 重新抛出异常 (re-throw exception) throw;，以便让更外层的 catch 块或系统默认的异常处理机制来处理异常。
④ 避免空的 catch(...) 块，或者仅仅打印一条模糊信息就忽略异常的做法。
1
#include <iostream>
2
#include <stdexcept>
3
4
void mightThrow() {
5
throw std::runtime_error("Unexpected error occurred.");
6
}
7
8
int main() {
9
try {
10
mightThrow();
11
} catch (const std::runtime_error& e) { // ✅ 捕获特定异常类型 (Catch specific exception type)
12
std::cerr << "Caught runtime_error: " << e.what() << std::endl;
13
// 针对 runtime_error 的处理逻辑 (Handling logic for runtime_error)
14
} catch (const std::exception& e) { // ✅ 捕获其他标准异常 (Catch other standard exceptions)
15
std::cerr << "Caught exception: " << e.what() << std::endl;
16
// 针对其他标准异常的处理逻辑 (Handling logic for other standard exceptions)
17
} catch (...) { // ✅ 捕获所有其他异常，并重新抛出 (Catch all others and re-throw)
18
std::cerr << "Caught unknown exception, re-throwing." << std::endl;
19
throw; // 重新抛出当前异常 (Re-throw the current exception)
20
}
21
return 0;
22
}
在这个修正后的例子中，我们首先尝试捕获 std::runtime_error 和 std::exception，然后使用 catch(...) 捕获所有其他未知的异常，并在 catch(...) 块中重新抛出异常，确保错误不会被忽略。
B.3 陷阱三：在析构函数中抛出异常 (Pitfall 3: Throwing Exceptions in Destructors)
绝对不要在析构函数 (destructor) 中抛出异常。如果在栈展开 (stack unwinding) 过程中，析构函数抛出异常，会导致程序立即终止 (terminate)。这是一个非常严重的错误，必须避免。
B.3.1 问题描述：程序终止 (Problem Description: Program Termination)
① 当异常被抛出并且栈展开开始时，程序会按照相反的顺序调用栈上所有局部对象的析构函数。
② 如果在栈展开过程中，某个析构函数也抛出了异常，C++ 运行时环境会调用 std::terminate() 函数，导致程序立即终止。
③ 这是因为在异常处理机制中，不允许同时存在两个未处理的异常。析构函数抛出异常会使情况变得非常复杂和难以预测。
④ 析构函数抛出异常还会阻止其他对象的析构函数被调用，可能导致资源泄漏 (resource leaks) 和程序状态不一致。
1
#include <iostream>
2
#include <stdexcept>
3
4
class Resource {
5
public:
6
Resource(const std::string& name) : name_(name) {
7
std::cout << "Resource '" << name_ << "' acquired." << std::endl;
8
}
9
~Resource() {
10
std::cout << "Destructor for Resource '" << name_ << "' called." << std::endl;
11
if (name_ == "RiskyResource") {
12
throw std::runtime_error("Exception from destructor of RiskyResource!"); // ⚠️ 析构函数抛出异常 (Exception thrown from destructor)
13
}
14
std::cout << "Resource '" << name_ << "' released." << std::endl;
15
}
16
private:
17
std::string name_;
18
};
19
20
void func() {
21
Resource r1("SafeResource");
22
Resource r2("RiskyResource");
23
throw std::runtime_error("Exception from func!");
24
}
25
26
int main() {
27
try {
28
func();
29
} catch (const std::exception& e) {
30
std::cerr << "Caught exception: " << e.what() << std::endl;
31
}
32
std::cout << "Program continues (or does it?)." << std::endl; // 永远不会执行到这里 (Never reaches here)
33
return 0;
34
}
在这个例子中，RiskyResource 的析构函数抛出了异常。当 func() 抛出异常导致栈展开时，RiskyResource 的析构函数被调用，再次抛出异常，程序会立即终止，"Program continues" 将永远不会被打印。
B.3.2 解决方案：避免在析构函数中抛出异常 (Solution: Avoid Throwing Exceptions in Destructors)
① 永远不要让析构函数抛出异常。这是 C++ 异常处理中的黄金法则 (golden rule)。
② 如果析构函数中可能发生错误，应该在析构函数内部捕获并处理 (catch and handle) 这些错误，例如记录错误日志，或者设置错误状态标志。
③ 如果必须将错误信息传递给外部，可以考虑使用状态标志 (status flag) 或 回调函数 (callback function) 等机制，而不是抛出异常。
④ 对于可能抛出异常的操作，应该将其移出析构函数，放到其他的成员函数中，并让用户显式地调用这些函数，以便在必要时处理异常。
1
#include <iostream>
2
#include <stdexcept>
3
4
class Resource {
5
public:
6
Resource(const std::string& name) : name_(name) {
7
std::cout << "Resource '" << name_ << "' acquired." << std::endl;
8
}
9
~Resource() {
10
std::cout << "Destructor for Resource '" << name_ << "' called." << std::endl;
11
try {
12
if (name_ == "RiskyResource") {
13
// 模拟可能出错的操作 (Simulate a potentially failing operation)
14
throw std::runtime_error("Error during resource release!");
15
}
16
std::cout << "Resource '" << name_ << "' released." << std::endl;
17
} catch (const std::exception& e) {
18
std::cerr << "Error in destructor of Resource '" << name_ << "': " << e.what() << std::endl; // 捕获并记录错误 (Catch and log the error)
19
// 在析构函数中处理错误，例如记录日志，设置错误状态等 (Handle error in destructor, e.g., log, set error status)
20
}
21
}
22
private:
23
std::string name_;
24
};
25
26
void func() {
27
Resource r1("SafeResource");
28
Resource r2("RiskyResource");
29
throw std::runtime_error("Exception from func!");
30
}
31
32
int main() {
33
try {
34
func();
35
} catch (const std::exception& e) {
36
std::cerr << "Caught exception: " << e.what() << std::endl;
37
}
38
std::cout << "Program continues." << std::endl; // 现在可以执行到这里 (Now it reaches here)
39
return 0;
40
}
在这个修正后的例子中，RiskyResource 的析构函数内部使用了 try-catch 块，捕获了可能发生的异常，并记录了错误信息，但没有将异常抛出析构函数之外。这样就避免了程序终止的风险。
B.4 陷阱四：资源泄漏 (Pitfall 4: Resource Leaks)
如果在异常抛出后，资源没有被正确释放 (resource not properly released)，就会发生资源泄漏。在 C++ 中，最常见的资源泄漏是内存泄漏，但也包括文件句柄、锁等其他资源的泄漏。
B.4.1 问题描述：未释放资源 (Problem Description: Unreleased Resources)
① 在传统的 C 风格的资源管理中，通常使用 malloc/free 或 new/delete 手动分配和释放内存，使用 fopen/fclose 打开和关闭文件等。
② 如果在资源分配后和资源释放前，代码抛出了异常，并且没有合适的异常处理机制来释放资源，就会导致资源泄漏。
③ 尤其是在复杂的函数或循环中，如果有多处可能抛出异常，手动管理资源很容易出错，导致难以追踪的资源泄漏问题。
1
#include <iostream>
2
#include <fstream>
3
#include <stdexcept>
4
5
void processFile(const std::string& filename) {
6
std::ofstream file;
7
file.open(filename); // 打开文件 (Open file)
8
if (!file.is_open()) {
9
throw std::runtime_error("Failed to open file: " + filename);
10
}
11
// ... 执行文件写入操作 (Perform file writing operations) ...
12
if (/* 某些写入条件失败 (some writing condition fails) */ true) {
13
throw std::runtime_error("Error during file writing."); // ⚠️ 抛出异常 (Exception thrown)
14
}
15
file.close(); // ⚠️ 如果上面抛出异常，这行代码不会执行 (This line will not be executed if exception is thrown above)
16
} // ❌ 文件句柄可能泄漏 (File handle might leak)
17
18
int main() {
19
try {
20
processFile("example.txt");
21
} catch (const std::exception& e) {
22
std::cerr << "Exception: " << e.what() << std::endl;
23
}
24
return 0;
25
}
在这个例子中，如果在文件写入过程中抛出异常，file.close() 将不会被执行，导致文件句柄泄漏。虽然在这个简单例子中泄漏的文件句柄可能在程序退出时被操作系统回收，但在更复杂的场景中，例如长时间运行的服务器程序，资源泄漏会逐渐积累，最终导致系统资源耗尽。
B.4.2 解决方案：使用 RAII (Resource Acquisition Is Initialization) (Solution: Use RAII (Resource Acquisition Is Initialization))
① RAII (Resource Acquisition Is Initialization) 是一种 C++ 编程惯用法，用于实现自动资源管理，是解决资源泄漏问题的最佳实践 (best practice)。
② RAII 的核心思想是：将资源的生命周期与对象的生命周期绑定。在对象构造时获取资源，在对象析构时自动释放资源。
③ 通过使用 RAII，可以确保无论是否发生异常，资源都能够被正确地释放，从而避免资源泄漏。
④ C++ 标准库提供了许多 RAII 资源管理类，例如智能指针 (std::unique_ptr, std::shared_ptr) 用于内存管理，文件流 (std::ofstream, std::ifstream, std::fstream) 用于文件管理，锁 (std::lock_guard, std::unique_lock) 用于互斥锁管理等。
1
#include <iostream>
2
#include <fstream>
3
#include <stdexcept>
4
#include <memory> // 智能指针头文件 (Header for smart pointers)
5
6
void processFileRAII(const std::string& filename) {
7
std::ofstream file(filename); // ✅ RAII: 文件流对象在构造时打开文件 (RAII: File stream object opens file in constructor)
8
if (!file.is_open()) {
9
throw std::runtime_error("Failed to open file: " + filename);
10
}
11
// ... 执行文件写入操作 (Perform file writing operations) ...
12
if (/* 某些写入条件失败 (some writing condition fails) */ true) {
13
throw std::runtime_error("Error during file writing."); // ⚠️ 抛出异常 (Exception thrown)
14
}
15
// file.close() 不再需要显式调用 (No need to explicitly call file.close())
16
} // ✅ RAII: 文件流对象 file 在离开作用域时自动调用析构函数，关闭文件 (RAII: File stream object 'file' automatically calls destructor when leaving scope, closing the file)
17
18
int main() {
19
try {
20
processFileRAII("example_raii.txt");
21
} catch (const std::exception& e) {
22
std::cerr << "Exception: " << e.what() << std::endl;
23
}
24
return 0;
25
}
在这个修正后的例子中，我们使用了 std::ofstream file(filename) 来打开文件。std::ofstream 对象就是一个 RAII 资源管理类。当 processFileRAII 函数结束或者在函数执行过程中抛出异常导致栈展开时，局部对象 file 会被销毁，其析构函数会被自动调用，析构函数会负责关闭文件，从而确保文件句柄不会泄漏。
智能指针 (Smart Pointers) 与内存管理 (Memory Management)
对于动态分配的内存，可以使用智能指针 std::unique_ptr 或 std::shared_ptr 来实现 RAII 内存管理。
1
#include <iostream>
2
#include <memory>
3
4
void allocateMemoryRAII() {
5
std::unique_ptr<int> ptr(new int(42)); // ✅ RAII: unique_ptr 管理动态分配的 int (RAII: unique_ptr manages dynamically allocated int)
6
// ... 使用 ptr 指向的内存 (Use memory pointed to by ptr) ...
7
if (/* 某些条件导致异常 (some condition causes exception) */ true) {
8
throw std::runtime_error("Error during memory operation."); // ⚠️ 抛出异常 (Exception thrown)
9
}
10
// delete ptr; 不再需要显式调用 delete (No need to explicitly call delete ptr)
11
} // ✅ RAII: unique_ptr 在离开作用域时自动释放内存 (RAII: unique_ptr automatically releases memory when leaving scope)
12
13
int main() {
14
try {
15
allocateMemoryRAII();
16
} catch (const std::exception& e) {
17
std::cerr << "Exception: " << e.what() << std::endl;
18
}
19
return 0;
20
}
在这个例子中，std::unique_ptr<int> ptr(new int(42)) 创建了一个智能指针 ptr 来管理动态分配的 int 内存。当 allocateMemoryRAII 函数结束或抛出异常时，ptr 对象会被销毁，其析构函数会自动调用 delete ptr 释放内存，避免内存泄漏。
总结 (Summary)
使用 RAII 是编写异常安全代码的关键。通过 RAII，可以有效地管理各种资源，确保在异常情况下资源能够被正确地释放，从而避免资源泄漏，提高程序的健壮性和可靠性。在现代 C++ 编程中，应该尽可能地使用 RAII 来管理所有需要管理的资源。
B.5 陷阱五：忽略异常 (Pitfall 5: Ignoring Exceptions)
忽略异常 (ignoring exceptions)，即捕获异常后不进行任何处理，或者仅仅简单地记录日志就继续执行程序，是一种非常危险的做法。这会掩盖程序中潜在的错误，导致程序行为不可预测。
B.5.1 问题描述：掩盖错误和程序行为异常 (Problem Description: Hiding Errors and Abnormal Program Behavior)
① 空的 catch 块 (empty catch block)，或者只包含简单日志输出的 catch 块，是最常见的忽略异常的形式。
② 忽略异常意味着程序没有对错误情况做出适当的响应，错误可能被传递下去，导致更严重的问题在后续代码中爆发，或者程序在错误的状态下继续运行，产生不可靠的结果。
③ 忽略异常会极大地增加调试难度，因为错误发生的最初位置被掩盖了，错误的影响可能会在远离错误源头的地方才显现出来。
④ 在某些情况下，忽略异常可能会导致安全漏洞 (security vulnerabilities)，例如，如果一个安全检查操作抛出异常被忽略，可能会导致未授权的访问。
1
#include <iostream>
2
#include <stdexcept>
3
4
void riskyOperation() {
5
// 假设这里可能抛出异常 (Assume exception might be thrown here)
6
throw std::runtime_error("Risky operation failed.");
7
}
8
9
void processData() {
10
try {
11
riskyOperation();
12
} catch (const std::exception& e) {
13
// ⚠️ 忽略异常 (Ignoring exception)
14
std::cerr << "Warning: riskyOperation failed, but we'll continue anyway." << std::endl;
15
// 空的 catch 块或者简单的日志输出都属于忽略异常 (Empty catch block or simple logging is considered ignoring exception)
16
}
17
// 程序继续执行，但可能依赖于 riskyOperation 的结果，导致错误 (Program continues, but might depend on the result of riskyOperation, leading to errors)
18
std::cout << "Data processing continues..." << std::endl;
19
}
20
21
int main() {
22
processData();
23
std::cout << "Program finished." << std::endl;
24
return 0;
25
}
在这个例子中，riskyOperation() 抛出的异常被 catch 块捕获，但仅仅打印了一条警告信息就被忽略了。processData() 函数会继续执行，但由于 riskyOperation() 失败，后续的数据处理可能会基于错误的数据，导致程序行为异常。
B.5.2 解决方案：妥善处理或重新抛出异常 (Solution: Handle Properly or Re-throw Exception)
① 每个 catch 块都应该有明确的处理逻辑，根据捕获的异常类型和程序上下文，采取合适的措施。
② 处理策略 (handling strategies) 可能包括：
▮▮▮▮⚝ 修复错误 (fix the error)：在 catch 块中尝试恢复程序状态，修复错误，然后继续执行。但这通常比较困难，只适用于非常明确且可恢复的错误情况。
▮▮▮▮⚝ 回滚操作 (rollback operation)：如果当前操作是一个事务的一部分，发生错误时应该回滚事务，撤销已经执行的操作，保持数据一致性。
▮▮▮▮⚝ 记录错误日志 (log error)：记录详细的错误信息，包括异常类型、错误消息、发生错误的时间和位置等，以便后续分析和调试。
▮▮▮▮⚝ 向用户报告错误 (report error to user)：对于用户界面程序，应该向用户显示友好的错误提示信息，告知用户操作失败的原因。
▮▮▮▮⚝ 清理资源 (cleanup resources)：确保在异常发生时，已经分配的资源（例如内存、文件句柄、锁）被正确地释放，避免资源泄漏。
▮▮▮▮⚝ 重新抛出异常 (re-throw exception)：如果当前 catch 块无法完全处理异常，或者应该由更外层的调用者来处理异常，应该使用 throw; 重新抛出当前异常。
③ 避免空的 catch 块，除非你非常确定这种情况是完全可以接受的，并且经过了仔细的考虑和测试。
④ 不要仅仅为了“吞噬”异常而使用 catch(...)。如果使用 catch(...)，务必重新抛出异常，除非你有明确的理由和策略来处理所有类型的异常。
1
#include <iostream>
2
#include <stdexcept>
3
4
void riskyOperation() {
5
throw std::runtime_error("Risky operation failed.");
6
}
7
8
void processDataCorrectly() {
9
try {
10
riskyOperation();
11
} catch (const std::runtime_error& e) {
12
std::cerr << "Error: riskyOperation failed: " << e.what() << std::endl; // 记录错误日志 (Log error)
13
// 可以选择重新抛出异常，让调用者处理 (Optionally re-throw exception for caller to handle)
14
// throw;
15
}
16
// ... 或者根据错误情况采取其他处理措施 (Or take other handling actions based on error) ...
17
std::cout << "Data processing continues (with potential error handled)." << std::endl;
18
}
19
20
int main() {
21
processDataCorrectly();
22
std::cout << "Program finished." << std::endl;
23
return 0;
24
}
在这个修正后的例子中，catch 块捕获了 std::runtime_error 异常后，首先记录了详细的错误日志。然后，可以根据具体需求选择是否重新抛出异常，或者采取其他错误处理措施。例如，可以设置一个错误状态标志，通知后续代码操作失败，或者尝试进行一些错误恢复操作。总之，不能简单地忽略异常，必须对异常做出明确的响应。
B.6 陷阱六：过度使用异常 (Pitfall 6: Overuse of Exceptions)
异常 (exceptions) 应该用于处理 异常情况 (exceptional situations)，即那些不常发生、程序正常逻辑无法处理的错误。过度使用异常来处理普通的、可预期的错误 (expected errors)，会降低程序性能，增加代码复杂性，并使代码难以维护。
B.6.1 问题描述：性能下降和代码复杂性增加 (Problem Description: Performance Degradation and Increased Code Complexity)
① 异常处理机制 (exception handling mechanism) 的设计初衷并非用于处理普通的控制流。异常的抛出和捕获，特别是栈展开 (stack unwinding) 过程，会带来一定的性能开销。
② 如果频繁地使用异常来处理正常的错误情况，例如用户输入错误、文件不存在等，会显著降低程序性能。
③ 异常处理的代码结构 (try-catch 块) 会使代码逻辑分散，增加代码的认知负担 (cognitive load)，降低代码的可读性和可维护性。
④ 过度依赖异常处理，可能会导致错误处理逻辑与正常的业务逻辑混杂在一起，使得代码结构混乱，难以理解和修改。
1
#include <iostream>
2
#include <fstream>
3
#include <stdexcept>
4
5
int readFileSize(const std::string& filename) {
6
std::ifstream file(filename);
7
if (!file.is_open()) {
8
throw std::runtime_error("File not found: " + filename); // ⚠️ 使用异常处理文件不存在的情况 (Using exception to handle file not found)
9
}
10
file.seekg(0, std::ios::end);
11
return file.tellg();
12
}
13
14
int main() {
15
std::string filename;
16
std::cout << "Enter filename: ";
17
std::cin >> filename;
18
try {
19
int size = readFileSize(filename);
20
std::cout << "File size: " << size << " bytes." << std::endl;
21
} catch (const std::exception& e) {
22
std::cerr << "Error: " << e.what() << std::endl; // 捕获文件不存在的异常 (Catching file not found exception)
23
}
24
return 0;
25
}
在这个例子中，使用异常来处理文件不存在的情况。但文件不存在其实是一种可预期的、普通的情况，用户可能输入错误的文件名。使用异常来处理这种情况显得有些过度。
B.6.2 解决方案：使用错误码或状态标志处理可预期错误 (Solution: Use Error Codes or Status Flags for Expected Errors)
① 对于可预期的、普通的错误情况，例如：
▮▮▮▮⚝ 无效的用户输入 (invalid user input)
▮▮▮▮⚝ 文件不存在 (file not found)
▮▮▮▮⚝ 网络连接超时 (network connection timeout)
▮▮▮▮⚝ 资源暂时不可用 (resource temporarily unavailable)
▮▮▮▮⚝ ...
应该使用错误码 (error codes)、状态标志 (status flags)、返回值 (return values) 等机制来处理，而不是异常。
② 异常应该保留用于处理真正异常的、不可预期的错误情况，例如：
▮▮▮▮⚝ 内存耗尽 (out of memory)
▮▮▮▮⚝ 系统崩溃 (system crash)
▮▮▮▮⚝ 硬件故障 (hardware failure)
▮▮▮▮⚝ 程序逻辑无法处理的严重错误 (severe errors that program logic cannot handle)
▮▮▮▮⚝ ...
③ 使用错误码或状态标志处理可预期错误，可以提高程序性能，简化代码逻辑，并使错误处理代码与正常的业务逻辑分离，提高代码的可读性和可维护性。
1
#include <iostream>
2
#include <fstream>
3
#include <system_error> // std::error_code, std::generic_category
4
5
std::error_code readFileSizeCorrectly(const std::string& filename, int& size) {
6
std::ifstream file(filename);
7
if (!file.is_open()) {
8
return std::error_code(errno, std::generic_category()); // ✅ 使用错误码表示文件打开失败 (Using error code to indicate file open failure)
9
}
10
file.seekg(0, std::ios::end);
11
size = file.tellg();
12
return std::error_code(); // ✅ 返回空错误码表示成功 (Return empty error code for success)
13
}
14
15
int main() {
16
std::string filename;
17
std::cout << "Enter filename: ";
18
std::cin >> filename;
19
int size = 0;
20
std::error_code ec = readFileSizeCorrectly(filename, size); // 获取错误码 (Get error code)
21
if (ec) {
22
std::cerr << "Error opening file: " << ec.message() << std::endl; // 检查和处理错误码 (Check and handle error code)
23
} else {
24
std::cout << "File size: " << size << " bytes." << std::endl;
25
}
26
return 0;
27
}
在这个修正后的例子中，readFileSizeCorrectly 函数使用 std::error_code 来返回错误信息。文件打开失败时，返回一个包含错误码的 std::error_code 对象；成功时，返回一个空的 std::error_code 对象。main 函数通过检查 std::error_code 对象来判断文件操作是否成功，并进行相应的处理。这种方式更适合处理文件不存在这种可预期的错误。
选择异常还是错误码 (Choosing between Exceptions and Error Codes)
| 特性 (Feature) | 异常 (Exceptions) | 错误码 (Error Codes) |
|---|---|---|
| 适用场景 (Use Cases) | 异常情况、不可预期错误、程序逻辑无法处理的错误 | 可预期错误、普通错误、性能敏感的场景 |
| 性能 (Performance) | 抛出和捕获有性能开销，正常执行路径性能影响小 | 性能开销小，错误检查通常为简单的条件判断 |
| 代码结构 (Code Structure) | try-catch 块，错误处理代码与正常逻辑分离，但可能分散 | 错误检查代码与正常逻辑混合，但结构更线性 |
| 错误信息 (Error Information) | 可以携带丰富的异常对象，包含类型信息和详细错误描述 | 通常只返回整数错误码，错误信息相对简单，需要额外机制传递详细信息 |
| 错误处理流程 (Error Handling Flow) | 栈展开，自动传播到最近的 catch 块 | 需要手动检查返回值，逐层传递错误码 |
| 适用语言 (Language Support) | C++, Java, Python, C# 等 | C, C++, Go, Rust 等 |
总结 (Summary)
合理地选择异常和错误码，取决于具体的应用场景和需求。对于 C++ 来说，异常处理是处理异常情况和保证程序健壮性的重要机制，但不是万能的错误处理方案。 应该根据错误的性质和频率，选择最合适的错误处理方式，避免过度使用或滥用异常处理。
Appendix C: 附录 C：C++ 异常安全级别速查表 (Appendix C: C++ Exception Safety Level Cheat Sheet)
Appendix C：C++ 异常安全级别速查表 (Appendix C: C++ Exception Safety Level Cheat Sheet)
本附录旨在为读者提供一个快速参考指南，总结了 C++ 中不同的异常安全级别及其含义。理解这些级别对于编写健壮和可靠的 C++ 代码至关重要。速查表将帮助开发者在设计和实现函数及类时，清晰地了解其异常安全保证，从而更好地处理潜在的异常情况。
以下速查表总结了 C++ 中常见的四种异常安全级别，从最弱到最强依次排列。
⚝ 不提供保证 (No Guarantee) 💔
① 描述 (Description): 这是最弱的异常安全级别。在这种级别下，如果操作抛出异常，程序的状态可能会变得不确定。程序可能崩溃，资源可能泄漏，对象可能处于无效或损坏的状态。
② 特征 (Characteristics):
▮▮▮▮ⓒ 状态不确定 (Indeterminate State): 异常发生后，程序或对象的状态无法预测，可能处于任何状态。
▮▮▮▮ⓓ 资源泄漏风险 (Resource Leaks Risk): 可能发生资源泄漏，例如内存泄漏、文件句柄泄漏等。
▮▮▮▮ⓔ 对象可能损坏 (Object Corruption): 对象自身可能被破坏，不再能正常使用。
⑥ 适用场景 (Use Cases): 应尽量避免这种情况。通常只在非常早期的原型开发或对异常安全要求极低的情况下出现。
⑦ 示例 (Example):
1
void no_guarantee_function() {
2
int* ptr = new int[10];
3
// ... 如果此处抛出异常，ptr 指向的内存将泄漏
4
if (rand() % 2 == 0) {
5
throw std::runtime_error("Oops! Something went wrong without guarantee.");
6
}
7
delete[] ptr;
8
}
⚝ 基本保证 (Basic Guarantee) 🛠️
① 描述 (Description): 提供基本保证的函数或操作，在抛出异常后，承诺程序不会崩溃，并且不会发生资源泄漏。然而，程序的状态可能会发生变化，但对象仍然处于有效 (但可能是已修改) 的状态。
② 特征 (Characteristics):
▮▮▮▮ⓒ 程序不崩溃 (No Program Crash): 即使发生异常，程序也能继续运行，不会直接终止。
▮▮▮▮ⓓ 无资源泄漏 (No Resource Leaks): 所有已分配的资源（例如内存、文件句柄）都会被正确释放。
▮▮▮▮ⓔ 对象处于有效状态 (Objects in Valid State): 对象在异常后仍然处于某种有效状态，可以安全地析构，但其具体值可能与操作开始前不同。
⑥ 适用场景 (Use Cases): 这是大多数函数和操作应该至少提供的保证。基本保证是异常安全编程的最低要求。
⑦ 示例 (Example):
1
#include <stdexcept>
2
#include <memory>
3
4
void basic_guarantee_function() {
5
std::unique_ptr<int[]> ptr(new int[10]);
6
// ... 如果此处抛出异常，unique_ptr 会自动释放内存，避免泄漏
7
if (rand() % 2 == 0) {
8
throw std::runtime_error("Oops! Something went wrong with basic guarantee.");
9
}
10
// ... 后续操作
11
}
⚝ 强异常安全保证 (Strong Exception Safety Guarantee) 💪
① 描述 (Description): 强异常安全保证是最理想的级别。提供强异常安全保证的函数或操作，在抛出异常时，不仅满足基本保证的所有条件，而且承诺操作要么完全成功，要么完全不生效，程序状态和所有对象的状态都恢复到操作开始之前的状态，如同操作从未发生过一样。这也被称为“原子性 (atomicity)” 或 “commit-or-rollback (提交或回滚)” 语义。
② 特征 (Characteristics):
▮▮▮▮ⓒ 事务性 (Transactional): 操作的行为像一个事务，要么完全完成，要么完全回滚。
▮▮▮▮ⓓ 操作失败无副作用 (No Side Effects on Failure): 如果操作失败并抛出异常，程序的状态和对象的状态都保持不变，就像操作从未被调用过。
▮▮▮▮ⓔ 满足基本保证 (Satisfies Basic Guarantee): 同时满足基本保证的所有条件：程序不崩溃，无资源泄漏，对象处于有效状态。
⑥ 适用场景 (Use Cases): 对于需要高度可靠性和数据一致性的系统，例如金融系统、数据库系统等，强异常安全保证至关重要。
⑦ 示例 (Example): 使用 “Copy-and-Swap (复制并交换)” 惯用法可以实现赋值操作的强异常安全保证。
1
#include <string>
2
#include <stdexcept>
3
#include <algorithm>
4
5
class StrongExceptionSafeClass {
6
private:
7
std::string data;
8
public:
9
StrongExceptionSafeClass(std::string d) : data(std::move(d)) {}
10
11
StrongExceptionSafeClass& operator=(const StrongExceptionSafeClass& other) {
12
if (this != &other) {
13
StrongExceptionSafeClass temp = other; // 复制构造函数，可能抛出异常
14
swap(temp); // 交换操作，通常应该是 noexcept
15
}
16
return *this;
17
}
18
19
void swap(StrongExceptionSafeClass& other) noexcept {
20
std::swap(data, other.data);
21
}
22
23
// ... 其他成员函数
24
};
⚝ 无异常保证 (No-throw Guarantee) / 绝对保证 (Nothrow Guarantee) 🛡️
① 描述 (Description): 这是最强的异常安全级别。提供无异常保证的函数或操作，承诺永远不会抛出异常。这种函数通常被声明为 noexcept。
② 特征 (Characteristics):
▮▮▮▮ⓒ 永不抛出异常 (Never Throws Exceptions): 保证在任何情况下都不会抛出异常。
▮▮▮▮ⓓ 最高性能潜力 (Highest Performance Potential): 由于不需要考虑异常处理的开销，这类函数通常具有最高的性能潜力，并且编译器可以进行更多优化。
▮▮▮▮ⓔ 隐式满足所有其他保证 (Implicitly Satisfies All Other Guarantees): 由于不抛出异常，因此隐式地满足了基本保证和强异常安全保证。
⑥ 适用场景 (Use Cases): 析构函数 (destructor)、移动构造函数 (move constructor)、移动赋值运算符 (move assignment operator)、swap 函数等应该尽可能提供无异常保证。 标准库的许多操作，特别是与内存管理和资源管理相关的操作，都依赖于无异常保证。
⑦ 示例 (Example):
1
class NothrowClass {
2
public:
3
~NothrowClass() noexcept {
4
// 析构函数不应抛出异常
5
// ... 资源清理代码
6
}
7
8
NothrowClass(NothrowClass&& other) noexcept : data(std::move(other.data)) {
9
// 移动构造函数通常应该是 noexcept
10
}
11
12
NothrowClass& operator=(NothrowClass&& other) noexcept {
13
if (this != &other) {
14
data = std::move(other.data);
15
}
16
return *this;
17
}
18
private:
19
int data;
20
};
总结表:
| 异常安全级别 (Exception Safety Level) | 保证 (Guarantee) | 资源泄漏 (Resource Leaks) | 程序状态 (Program State) | 对象状态 (Object State) | 性能影响 (Performance Impact) | 适用性 (Applicability) |
|---|---|---|---|---|---|---|
| 不提供保证 (No Guarantee) | 无 (None) | 可能 (Possible) | 不确定 (Indeterminate) | 可能损坏 (Potentially Corrupted) | 高 (High - due to errors) | 应避免 (To be avoided) |
| 基本保证 (Basic Guarantee) | 程序不崩溃，无资源泄漏 (Program doesn't crash, no resource leaks) | 无 (None) | 有效但可能已修改 (Valid but possibly modified) | 有效 (Valid) | 中 (Medium) | 大多数函数和操作的最低要求 (Minimum requirement for most functions and operations) |
| 强异常安全保证 (Strong Exception Safety) | 操作要么成功，要么完全回滚 (Operation either succeeds or completely rolls back) | 无 (None) | 操作前状态 (State before operation) | 操作前状态 (State before operation) | 中等偏高 (Medium to High) | 高可靠性系统，事务性操作 (High-reliability systems, transactional operations) |
| 无异常保证 (No-throw Guarantee) | 永不抛出异常 (Never throws exceptions) | 无 (None) | 稳定 (Stable) | 稳定 (Stable) | 低 (Low) | 析构函数，移动操作，交换操作，性能关键代码 (Destructors, move operations, swap operations, performance-critical code) |
理解并选择合适的异常安全级别，是编写高质量 C++ 代码的关键环节。希望此速查表能够帮助您更好地理解和应用 C++ 异常安全编程。
Appendix D: 参考文献 (References)
附录 D：参考文献 (References)
本附录列出本书编写过程中参考的重要书籍、标准文档、论文和在线资源，为读者提供进一步学习的参考。 (This appendix lists important books, standard documents, papers, and online resources referenced during the writing of this book, providing readers with references for further study.)
① 书籍 (Books)
▮▮▮▮ⓐ C++ Primer (C++ Primer), Stanley B. Lippman, Josée Lajoie, Barbara E. Moo, Addison-Wesley Professional, 第5版 (5th Edition), 2012.
▮▮▮▮ⓑ Effective C++: 改善程序与设计的55个具体做法 (Effective C++: 55 Specific Ways to Improve Your Programs and Designs), Scott Meyers, Addison-Wesley, 第3版 (3rd Edition), 2005.
▮▮▮▮ⓒ More Effective C++: 35个改善程序与设计的有效方法 (More Effective C++: 35 New Ways to Improve Your Programs and Designs), Scott Meyers, Addison-Wesley, 1996.
▮▮▮▮ⓓ Exceptional C++: 47个工程难题、编程问题和解答 (Exceptional C++: 47 Engineering Puzzles, Programming Problems, and Solutions), Herb Sutter, Addison-Wesley, 2000.
▮▮▮▮ⓔ More Exceptional C++: 40个新的工程难题、编程问题和解答 (More Exceptional C++: 40 New Engineering Puzzles, Programming Problems, and Solutions), Herb Sutter, Addison-Wesley, 2002.
▮▮▮▮ⓕ Effective Modern C++: 改善C++11和C++14的42个具体做法 (Effective Modern C++: 42 Specific Ways to Improve Your Use of C++11 and C++14), Scott Meyers, O'Reilly Media, 2014.
▮▮▮▮ⓖ The C++ Programming Language (The C++ Programming Language), Bjarne Stroustrup, Addison-Wesley, 第4版 (4th Edition), 2013.
▮▮▮▮ⓗ Modern C++ Design: Generic Programming and Design Patterns Applied (Modern C++ Design: Generic Programming and Design Patterns Applied), Andrei Alexandrescu, Addison-Wesley, 2001.
② 标准文档 (Standard Documents)
▮▮▮▮ⓐ ISO/IEC 14882:2011, Programming Languages — C++. 国际标准化组织 (International Organization for Standardization).
▮▮▮▮ⓑ ISO/IEC 14882:2014, Programming Languages — C++. 国际标准化组织 (International Organization for Standardization).
▮▮▮▮ⓒ ISO/IEC 14882:2017, Programming Languages — C++. 国际标准化组织 (International Organization for Standardization).
▮▮▮▮ⓓ ISO/IEC 14882:2020, Programming Languages — C++. 国际标准化组织 (International Organization for Standardization).
注意: 请查阅最新的C++标准文档以获取最准确和全面的信息。 (Note: Please refer to the latest C++ standard documents for the most accurate and comprehensive information.)
③ 在线资源 (Online Resources)
▮▮▮▮ⓐ cppreference.com: https://en.cppreference.com/ - 一个非常全面和权威的C++语言和标准库的在线参考网站。 (A comprehensive and authoritative online reference website for the C++ language and standard library.)
▮▮▮▮ⓑ isocpp.org: https://isocpp.org/ - 标准C++基金会 (Standard C++ Foundation) 的官方网站，提供C++标准、新闻、文章和资源。 (The official website of the Standard C++ Foundation, providing C++ standards, news, articles, and resources.)
▮▮▮▮ⓒ Stack Overflow (Stack Overflow): https://stackoverflow.com/ - 程序员问答社区，可以在这里找到很多关于C++异常处理的讨论和解决方案。 (A programmer Q&A community where you can find many discussions and solutions related to C++ exception handling.)
▮▮▮▮ⓓ C++ Core Guidelines (C++ Core Guidelines): https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines.html - 一组C++编程的指导原则，其中包含了关于异常处理的最佳实践建议。 (A set of guidelines for C++ programming, including best practices for exception handling.)
④ 论文与文章 (Papers and Articles)
▮▮▮▮ⓐ Exception-Safe Programming in C++ (C++中的异常安全编程), Herb Sutter, C++ Report, Vol. 6, No. 9, October 1994.
注意: 这只是一个基础的参考文献列表，随着C++技术的发展，新的书籍和资源不断涌现。建议读者持续关注C++领域的最新动态。 (Note: This is just a basic list of references. As C++ technology evolves, new books and resources are constantly emerging. Readers are advised to continuously pay attention to the latest developments in the C++ field.)