C++ Core Guidelines 整理目录

1. 哲学部分
2. 接口(Interface)部分
3. 函数部分
4. 类和类层次结构部分
5. 枚举部分
6. 资源管理部分
7. 性能部分
8. 错误处理

E: Error handling

E.1: Develop an error-handling strategy early in a design

• 翻译: 在设计早期制定一个错误处理策略。
• 原因: 为确保代码的健壮性和可维护性，应在项目初期就规划好如何处理可能出现的错误。

E.2: Throw an exception to signal that a function can’t perform its assigned task

• 翻译: 抛出异常以表明函数无法完成其指定的任务。
• 原因: 使用异常机制来清晰地表达程序执行中的错误情况，以便调用者可以采取适当的措施。

E.3: Use exceptions for error handling only

• 翻译: 仅将异常用于错误处理。
• 原因: 避免将异常用于正常的控制流逻辑，这样可以使错误处理代码与正常业务逻辑分离，提高代码的清晰度。

E.4: Design your error-handling strategy around invariants

• 翻译: 围绕不变量设计你的错误处理策略。
• 原因: 确保在发生错误时，对象的状态不会被破坏，保持对象内部的一致性。

E.5: Let a constructor establish an invariant, and throw if it cannot

• 翻译: 让构造函数建立一个不变量，并在无法做到时抛出异常。
• 原因: 构造函数应保证对象在其创建时处于有效状态，如果不能实现这一点，则应该通知用户。

E.6: Use RAII to prevent leaks

• 翻译: 使用 RAII（Resource Acquisition Is Initialization）防止泄漏。
• 原因: 通过 RAII 技术确保资源在使用完毕后能够正确释放，避免资源泄漏问题。

E.7: State your preconditions

• 翻译: 声明你的前置条件。
• 原因: 明确指出函数调用前必须满足的条件，帮助调用者正确使用函数，减少运行时错误。

E.8: State your postconditions

• 翻译: 声明你的后置条件。
• 原因: 翻译函数执行完成后应满足的条件，有助于验证函数是否按预期工作。

E.12: Use noexcept when exiting a function because of a throw is impossible or unacceptable

• 翻译: 在不可能或不可接受因为抛出异常而退出函数的情况下使用noexcept。
• 原因: 通过明确指出函数不会抛出异常来优化性能，并帮助编译器进行更严格的错误检查。

E.13: Never throw while being the direct owner of an object

• 翻译: 永远不要在直接拥有对象时抛出异常。
• 原因: 防止资源泄漏和未定义行为的发生，确保即使在发生异常时也能正确管理资源。

E.14: Use purpose-designed user-defined types as exceptions (not built-in types)

• 翻译: 使用专为异常设计的用户自定义类型（而不是内置类型）作为异常。
• 原因: 提高代码的可读性和可维护性，使得异常处理更加精确和有意义。

E.15: Throw by value, catch exceptions from a hierarchy by reference

• 翻译: 抛出时传递值，捕获异常层次结构中的异常时使用引用。
• 原因: 确保异常处理机制高效且避免潜在的对象切片问题。

E.16: Destructors, deallocation, swap, and exception type copy/move construction must never fail

• 翻译: 析构函数、释放内存、交换操作以及异常类型的拷贝/移动构造函数绝不能失败。
• 原因: 维护程序的稳定性，防止因资源管理相关的操作失败而导致的程序崩溃。

E.17: Don’t try to catch every exception in every function

• 翻译: 不要在每个函数中尝试捕捉所有异常。
• 原因: 仅在能够有效处理特定异常的地方捕捉它们，保持代码清晰和模块化。

E.18: Minimize the use of explicit try/catch

• 翻译: 尽量减少显式的 try/catch 使用。
• 原因: 降低代码复杂度，使异常传播自然，只在确实需要处理异常的地方使用 try/catch。

E.19: Use a final_action object to express cleanup if no suitable resource handle is available

• 翻译: 如果没有合适的资源处理器可用，则使用final_action对象表达清理操作。
• 原因: 确保资源在任何情况下都能得到正确的释放，避免资源泄漏。

E.25: If you can’t throw exceptions, simulate RAII for resource management

• 翻译: 如果你不能抛出异常，则模拟 RAII（Resource Acquisition Is Initialization）进行资源管理。
• 原因: 在无法使用异常的情况下，通过手动释放资源的方式确保资源不会泄漏，维持程序的稳定性。

E.26: If you can’t throw exceptions, consider failing fast

• 翻译: 如果你不能抛出异常，则考虑快速失败。
• 原因: 当检测到错误时立即停止程序执行，避免进一步的损害或不可预测的行为，使问题更容易定位和修复。

E.27: If you can’t throw exceptions, use error codes systematically

• 翻译: 如果你不能抛出异常，则系统地使用错误码。
• 原因: 作为一种替代机制来处理错误情况，确保所有可能的错误都能被明确识别和处理。

E.28: Avoid error handling based on global state (e.g. errno)

• 翻译: 避免基于全局状态（如errno）的错误处理。
• 原因: 全局状态容易导致意外的副作用和难以调试的问题，使用更明确的错误传递方式有助于提高代码的可读性和维护性。

E.30: Don’t use exception specifications

• 翻译: 不要使用异常规范（exception specifications）。
• 原因: 异常规范在 C++中已被弃用，并且可能导致性能开销和复杂性增加，推荐使用其他方法来处理异常。

E.31: Properly order your catch-clauses

• 翻译: 正确排列你的 catch 子句。
• 原因: 按照从具体到一般的顺序排列 catch 子句，确保特定类型的异常能够被正确捕获并处理，避免未捕获或错误捕获的情况发生。