继承 std::exception 是最稳妥起点，需显式声明虚析构函数和安全的 what() 实现，错误码应立即保存并用 std::error_code 跨平台处理，抛出时优先用 throw YourException(args...) 避免冗余拷贝。
继承 std::exception 是最稳妥的起点
直接继承 std::exception 能保证与标准异常体系兼容，所有 catch(const std::exception&) 都能捕获你的类。别从头写一个空类，也别继承 std::runtime_error 之类的具体子类——除非你明确需要它的语义（比如只用于运行时错误）。std::exception 提供了虚析构函数和 what() 接口，这是底线要求。
常见错误：忘记声明虚析构函数，导致派生类对象被 std::exception 引用捕获后析构不完整；或者重载 what() 但返回局部变量的指针（如临时 std::string.c_str()），造成悬垂指针。
实操建议：
- 在自定义类中显式声明
virtual ~YourException() noexcept override = default; -
what()返回值必须是const char*，且指向生命周期长于异常对象本身的内存（推荐用std::string成员 +.c_str()） - 构造函数接受可读信息（如
const std::string& msg或const char*），并存入成员变量
带错误码的异常类要小心 errno 和平台差异
如果异常需要携带系统错误码（比如封装 open() 失败），别直接存 errno 值——它可能在异常抛出前被其他系统调用覆盖。应在检测失败后立刻保存，例如：int saved_errno = errno;，再传入异常构造函数。
立即学习“C++免费学习笔记（深入）”；
Windows 下对应的是 GetLastError()，不能混用。跨平台项目建议统一用 std::error_code（来自 <system_error>）来承载错误码，再通过 std::error_condition 或自定义 std::error_category 实现语义映射。
实操建议：
- 避免在异常类里调用
strerror()或FormatMessage()—— 它们不是noexcept，可能再次抛异常 - 若需显示错误码，把码值作为独立成员（如
int m_errno），并在what()中格式化拼接（用std::to_string等安全方式） - 不要让异常类依赖全局状态（如静态缓冲区），否则多线程下会出问题
throw 时用 std::move 不提升性能，但别 throw e;
抛出已命名的异常对象（如 MyException e("msg"); throw e;）会触发拷贝构造，即使编译器做了复制省略（RVO/NRVO），语义上仍是“可能拷贝”。正确做法是直接 throw MyException("msg");，或用 throw std::move(e); 显式转移——后者在某些旧编译器或禁用优化时更可靠。
注意：C++11 起，异常对象本身总是以右值方式构造和传播，std::move 在 throw 表达式中只是强化意图，并非必需。但 throw e;（左值）确实存在冗余拷贝风险，尤其当你的异常类有大成员（如长字符串）时。
实操建议：
- 优先写
throw YourException(args...);，一行搞定，无中间变量 - 如果异常对象已在作用域中（比如工厂函数返回），用
throw std::move(obj); - 确认你的异常类移动构造函数是
noexcept（默认通常是），否则移动可能抛异常，导致程序终止
调试时 what() 返回空字符串？检查 std::string 生命周期
最常踩的坑：在 what() 里返回临时 std::string 的 c_str()，例如 return std::string("oops").c_str();。这个指针在 what() 返回后立即失效，catch 块里看到的就是乱码或空串。
根本原因是 std::string 对象在 what() 函数作用域结束时被销毁，而 c_str() 只是其内部缓冲区的视图。解决方案是让字符串数据长期驻留。
实操建议：
- 在异常类中用
std::string m_what_msg;成员存储消息，构造时初始化它，what()直接返回m_what_msg.c_str() - 避免在
what()内做任何字符串拼接、格式化操作——这些都可能抛异常或引入临时对象 - 如果必须动态生成消息（比如含变量值），提前在构造函数里完成，别拖到
what()才做
自定义异常真正的复杂点不在语法，而在确保 what() 的稳定性、错误码的及时捕获、以及抛出路径上的异常安全。很多看似“能跑”的实现，一开多线程或一加日志就暴露问题。
