C++ Core Guidelines 整理目录
- 哲学部分
- 接口(Interface)部分
- 函数部分
- 类和类层次结构部分
- 枚举部分
- 资源管理部分
- 性能部分
- 错误处理
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 子句，确保特定类型的异常能够被正确捕获并处理，避免未捕获或错误捕获的情况发生。
