异常用于异常情况而非控制流，资源获取失败或不可恢复错误时应抛出异常，需遵循异常安全三原则并使用RAII，明确异常类型且文档化，合理使用可提升代码健壮性。
在C++中，异常是一种强大的错误处理机制，但只有在正确使用时才能提高代码的健壮性和可维护性。滥用异常会导致性能下降、逻辑混乱，甚至资源泄漏。以下是关于何时抛出异常的实用准则和最佳实践。
1. 异常用于异常情况，而非控制流程
异常应只用于真正“异常”的情况，即程序无法正常继续执行的错误状态。它不应替代正常的控制流，比如用异常来处理用户输入错误或文件不存在等可预期情况。
例如，函数查找某个元素未果，返回 std::nullopt 或布尔值比抛出异常更合适。
建议：- 不要用异常实现循环或条件跳转
- 不要为可预见的失败（如配置文件缺失）抛出异常
2. 资源获取失败或不可恢复错误时抛出异常
当程序遇到无法继续执行的错误时，抛出异常是合理的。比如内存分配失败、数据库连接中断、关键配置加载失败等。
立即学习“C++免费学习笔记（深入）”；
标准库中，std::bad_alloc、std::runtime_error 等就是为此类情况设计的。
适用场景：
- 构造函数无法完成对象初始化
- 系统调用失败且无法降级处理
- 违反类不变量或前置条件
3. 保持异常安全的三原则
抛出异常时，必须确保代码满足异常安全保证：基本保证（不泄漏资源）、强保证（回滚到调用前状态）或无抛出保证。
使用 RAII（资源获取即初始化）是实现异常安全的关键。
做法：- 用智能指针管理动态内存
- 用锁包装器（如 std::lock_guard）管理互斥量
- 避免在析构函数中抛出异常
4. 明确异常类型并文档化
公开接口应明确说明可能抛出的异常类型。使用标准异常类继承体系，避免抛出原始类型（如 int、char*）。
例如，逻辑错误用 std::invalid_argument，运行时错误用 std::runtime_error。
推荐：- 自定义异常继承 std::exception 并重写 what()
- 在函数注释中标注可能抛出的异常
- 避免 throw() 或 noexcept 错误标注
基本上就这些。合理使用异常，能让错误处理更清晰；滥用则适得其反。关键是区分“异常”与“预期情况”，并始终保证资源安全。
