异常驱动流程不推荐作为主要控制流手段，仅适用于不可预测的外部故障（如文件打开失败、网络超时），而不适用于业务逻辑判断（如键存在性检查）；其性能开销大、可读性差、维护成本高，EAFP风格仅在特定低频、语义清晰场景下合理。
异常驱动流程在 Python 中不推荐作为主要控制流手段，它合理但有明确适用边界。
异常适合处理“意外”，而非“常规分支”
Python 的设计哲学强调“显式优于隐式”，用异常代替 if 判断来决定程序走向，会掩盖真实逻辑、降低可读性、增加调试难度。比如检查字典键是否存在，应优先用 dict.get() 或 in 判断，而不是靠 KeyError 捕获来跳转：
- ✅ 合理：打开文件失败、网络请求超时、JSON 解析出错——这些是不可预测的外部故障
- ❌ 不合理：用户输入为空、选项不在预设列表中、配置项缺失——这些属于业务逻辑的一部分，应主动校验
性能上，异常开销明显
抛出和捕获异常涉及栈回溯、对象创建和上下文管理，比普通条件判断慢一个数量级。在高频路径（如循环内部、核心算法）中用异常做流程控制，会带来可观的性能损耗。CPython 中一次 try/except 块本身开销不大，但一旦触发 raise，成本陡增。
可维护性与协作成本升高
异常驱动的代码容易形成“隐藏控制流”：函数表面无返回值提示，实际靠异常跳出；调用方若未预期该异常，就可能漏处理或误吞异常。团队协作中，这种写法需要额外文档或注释说明“此处可能抛 X 异常以表示 Y 情况”，反而违背了 Python 的简洁原则。
立即学习“Python免费学习笔记（深入）”；
存在折中实践：EAFP vs LBYL
Python 社区接受“请求宽恕比许可更容易”（EAFP）风格，例如：
try: value = obj.attr; except AttributeError: value = defaulttry: os.remove(path); except FileNotFoundError: pass
但这成立的前提是：“不存在”是常见且中性的状态，且异常发生频率低、语义清晰、处理简单。它不是通用替代方案，而是对特定场景（如并发环境下的竞态检查、动态属性访问）的优雅应对。
本质上，是否合理取决于上下文——把异常当 goto 用，不合理；把它当保险丝用，在真正出问题时熔断并提供上下文，就很合理。
