为何C++新增异常类型未派生自std::logic_error？

这些异常没有选择派生自std::logic_error，而是直接继承std::exception，是标准委员会权衡性能、语义合理性、历史兼容三方面因素后的结果，和「是否能通过前置检查避免」这个特征没有绑定关系：

• 最核心的决定因素是性能开销。std::logic_error的整个继承体系有个隐含要求：构造异常时必须传入错误描述字符串，绝大多数标准库实现会为这个字符串做动态内存分配。但bad_weak_ptr、bad_optional_access、bad_variant_access都是基础通用工具的配套异常，应用场景覆盖低延迟交易、嵌入式等对动态分配零容忍的领域，强制继承logic_error会平白增加无意义的开销。直接继承std::exception的话，实现方完全可以让what()方法直接返回静态写死的字符串字面量，不需要任何动态内存操作，抛异常的路径开销可以压到最低。
• 其次是异常分类的设计思路早就调整了。C98刚推出的时候，把异常分成std::logic_error（可通过开发阶段测试、调试完全避免的内部逻辑错误）和std::runtime_error（无法提前预判的运行时外部错误）两类，但后来标准委员会自己也承认这个二分法太僵化了。就拿无值optional访问来说，它既可能是开发者漏写判空的低级逻辑错误，也可能是业务代码里故意用异常传递「值不存在」状态的正常分支处理，硬把它塞到logic_error下面反而和实际工程用法脱节。从C11开始，新增的基础工具类配套异常基本都不会强行归入这两个旧分类，避免语义误导。
• 最后是历史实现的惯性影响。最早进入C11标准的bad_weak_ptr是从boost库迁移来的，boost版本的bad_weak_ptr从最初实现开始就直接继承std::exception，标准为了兼容已有boost用户的代码catch逻辑，没有改动它的继承关系。后来C17新增bad_optional_access、bad_variant_access的时候，也直接沿用了这个设计先例，保持同类工具的异常结构一致，减少用户的适配成本。

顺便纠正一个常见误区：很多人觉得「能通过前置检查避免的异常就该属于logic_error」，这个思路本身就站不住脚——真要严格按这个标准，几乎所有异常都能靠足够严谨的前置检查规避，那runtime_error存在的意义就没了，这个分类从根上就失效了。

内容的提问来源于stack exchange，提问作者Baruch