因为std::exception是扁平基类，异常匹配仅依赖静态继承关系，无法自动向上回溯；必须构建统一继承树（如AppError→IoError→FileNotFoundError），每层构造时拼接消息，catch中用throw;重抛以保类型。
为什么不能直接用 std::exception 做层级捕获
因为 std::exception 是扁平的基类，所有派生异常在 catch 时只能靠类型精确匹配，无法按“层级”向上回溯——比如你抛出 DatabaseConnectionError，却想用 catch (const DatabaseError&) 捕获，前提是后者必须是前者的直接或间接基类，且继承链不能断。
常见错误是把自定义异常写成独立类，没建继承树，结果 catch (const RuntimeError&) 根本捕不到 NetworkTimeoutError；或者误以为加个虚析构就自动有层级语义，其实没有——C++ 的异常匹配只看静态类型继承关系，不查运行时类型信息。
- 所有业务异常必须继承自一个统一根异常类（如
AppError），不能各自为政 - 根类必须声明虚析构函数，否则通过基类指针抛出时可能析构不完整
- 避免多继承，C++ 异常匹配不支持菱形继承下的模糊匹配
如何设计三层继承结构并保证 what() 正确拼接
典型分层是：根异常 → 领域异常（如 IoError） → 具体错误（如 FileNotFoundError）。关键点在于每层都应保留上层消息，并在构造时显式拼接，而不是覆盖。
错误做法是每个类都重写 what() 返回固定字符串；正确做法是让每层在构造时接收父级消息，再 prepend 自己的上下文。例如：
立即学习“C++免费学习笔记（深入）”；
class AppError : public std::exception {
protected:
std::string msg_;
public:
explicit AppError(std::string m) : msg_(std::move(m)) {}
const char* what() const noexcept override { return msg_.c_str(); }
};
<p>class IoError : public AppError {
public:
explicit IoError(std::string m) : AppError("IO error: " + m) {}
};</p><p>class FileNotFoundError : public IoError {
public:
FileNotFoundError(const std::string& path) : IoError("file not found: " + path) {}
};- 所有构造函数用
explicit防止隐式转换引发意外抛出 - 不要在
what()里做字符串拼接（可能抛异常），拼接必须在构造阶段完成 - 若需携带错误码，建议用成员变量存储，而非塞进
msg_字符串里——后续日志解析会更可靠
如何在 catch 块中安全地重新抛出并保留原始类型
直接写 throw;（无参数）才能保持原异常对象和动态类型；写 throw e; 会切片（slicing），丢失子类信息，导致上层只能捕获到基类。
典型陷阱是捕获后想加日志再抛，却写了 catch (const AppError& e) { log(e.what()); throw e; }——这已经不是原来的 FileNotFoundError 了，而是被转成 AppError 对象再抛出。
- 日志记录可用
e.what()，但抛出必须用无参throw; - 如果真要包装异常（如加堆栈或上下文），应新建一个更上层异常，并把原异常以引用或智能指针存为成员，再抛新异常
- 不要在
catch块里调用std::current_exception()再rethrow_exception()，除非你明确需要跨线程传递异常对象
为什么 std::nested_exception 不适合做业务层级框架
std::nested_exception 解决的是“异常嵌套”问题（如 A 函数抛异常，B 函数在 catch 后又抛另一个异常），它提供 nested_ptr() 让你能拿到被压入的原始异常指针。但它不提供任何层级分类能力，也不改变 catch 匹配逻辑。
有人试图用它模拟层级，比如在 DatabaseError 里嵌套 NetworkError，但这会让捕获逻辑变得不可预测：你到底该 catch (const DatabaseError&) 还是 catch (const NetworkError&)？实际中几乎没人这么用。
-
std::nested_exception适合底层库封装（如 ORM 层统一包装驱动异常），不适合业务代码定义领域层级 - 它的存在反而容易让人混淆“嵌套”和“继承”的区别——前者是因果链，后者是分类树
- 若真需要记录异常链，建议自己实现一个
cause_成员（std::exception_ptr类型），比依赖std::nested_exception更可控
真正难的是让团队所有人遵守同一套继承规范：什么时候该新增一层，什么时候该复用现有类，以及如何命名才能让 catch (const ValidationError&) 和 catch (const AuthorizationError&) 在语义上不重叠——这没法靠代码约束，得靠接口文档和 CR 规则。
