前言语法层面的try与except几乎没人不会写但把它放到一个真实项目里麻烦立刻来了这个函数该不该捕获捕获了之后是处理掉还是往上抛日志该在哪一层打为什么线上日志里满屏是「出错了」却看不到堆栈这些问题的共同点是——它们都不是语法问题而是边界问题。语法告诉你「可以怎么捕获」工程实践要回答的是「应该在哪一层捕获、捕获之后做什么」。本文不谈try语句的细枝末节专讲四件工程上的事EAFP 与 LBYL 两种风格的取舍、异常边界的划分原则、怎样用日志把现场留住、以及真实项目里异常层次该长什么样。文中出现的日志接口均以 Python 官方文档为准。一、EAFP 与 LBYL两种风格的取舍Python 术语表里把这两种风格定义得很清楚EAFPEasier to ask for forgiveness than permission先假定键或属性存在出问题再捕获异常。它的特征是「大量try/except」。LBYLLook before you leap先显式检查前置条件再执行。它的特征是「大量if」。同一个操作两种写法# 适用于 Python 3.8config {timeout: 30}# LBYL先查再取if timeout in config:timeout config[timeout]else:timeout 5# EAFP直接取出错再兜try:timeout config[timeout]except KeyError:timeout 5术语表里还点出了 LBYL 的一个硬伤在多线程环境下「看」和「跳」之间存在竞态。文档举的例子正是if key in mapping: return mapping[key]——在in判断和[]取值之间另一个线程可能已经把键删掉了。EAFP 没有这个窗口因为检查和取值是同一个原子操作。那么是不是无脑选 EAFP不是。取舍要看三件事判断维度倾向 EAFP倾向 LBYL操作是否幂等、代价是否低是检查本身有成本时反而不划算失败是否罕见正常流程、失败罕见失败是常态路径检查条件是否为真前置条件无法可靠预判能明确判定如文件权限举个具体的如果「键不存在」是很正常的一种输入比如可选配置项EAFP 更简洁如果一段数据有七成概率不符合条件那么先判断再决定走哪条分支可读性更好。但有一条红线不管选哪种风格都不要用异常来做「正常流程的主要分派手段」。如果一个for循环的正常退出要靠抛异常来实现代码就该重写了。二、异常边界在哪一层捕获、在哪一层上抛工程里最该建立的一个直觉是异常不是「在哪儿出错就在哪儿处理」而是「在哪儿知道该怎么办才在哪儿处理」。这就引出了「异常边界」的概念——一个边界就是一次「异常被翻译成结果」的转换点。典型的边界有三类对外的入口HTTP 处理函数、命令行main、消息消费者。这里必须捕获一切业务异常把它们翻译成对外的错误响应或退出码——因为外面是别人不能把堆栈甩给他。与外部系统的交界数据库、第三方接口、文件系统。这里捕获底层异常翻译成自己领域的异常把「对方怎么坏的」变成「我这边遇到了什么情况」。不可恢复的致命点启动时配置校验、数据库迁移。这里不该捕获让它直接失败、直接终止因为带着坏配置继续跑只会造成更难查的问题。反过来中间的业务逻辑层通常不该捕获。它的职责是把上层拿到的数据算对遇到自己处理不了的情况就往上抛。中间层到处try/except只有一个结果错误的原始信息在每一层都被磨掉一点最后到边界时已经面目全非。一条实用的自问清单问题如果答案是「否」我能在这里做点有意义的事吗转换、重试、降级、补充信息不要捕获让它往上走我捕获之后知道该返回什么吗不要捕获往上走这个异常在我这一层是「正常分支」还是「异常情况」若是异常情况往上走「能做点有意义的事」是唯一的捕获理由。纯粹为了「让程序别崩」而捕获恰恰是让程序在错误状态下继续跑比崩掉更危险。三、记录现场logging.exception 与 traceback捕获之后最该做的一件事是记录。这里有一个关键区别记录「出错了」和记录「怎么错的」是两件事。logging模块提供了专门的接口。官方文档对logger.exception()的说明是消息的解释方式与debug()相同并且会把异常信息加进日志消息这个方法只应在异常处理程序中被调用。它的效果等价于用error()再加上exc_infoTrue。# 适用于 Python 3.8import logginglogger logging.getLogger(__name__)def load_profile(user_id):try:return read_from_store(user_id)except OSError as exc:# ❌ 只记一句话堆栈全丢了logger.error(读取档案失败)# ✅ 连堆栈一起记下来logger.exception(读取档案失败user_id%s, user_id)raise两个细节值得强调logger.exception只在except块里有意义。文档写得很明确它需要当前正在处理的异常在except之外调用它拿到的是「没有异常信息」等于白打一行日志。参数化写法用%s占位不要把值拼进字符串。日志模块会延迟到真的需要输出时才做格式化而logger.error(失败 str(user_id))无论如何都要先拼一遍。官方文档里还提到一个更隐蔽的坑如果你预先拼好字符串并且内容里带有%日志模块还会拿它再格式化一次可能直接抛出格式化异常。还有一点堆栈要记在「离事发最近」的那一层。如果你打算在边界统一记录那中间层就不要再抛出新异常覆盖它否则原始堆栈就丢了。确实需要转换语义时用raise NewError(...) from exc把原始异常挂上这样边界处打印的堆栈里会包含完整的两段。raise单独一个词不带表达式的意思是「原样重新抛出当前异常」它保留原始堆栈是在except块里「记录完再往上抛」的标准写法。四、真实项目里的异常层次与三条纪律一个可用的工程化异常结构通常长这样# 适用于 Python 3.8# errors.py —— 处在依赖图最底层只依赖内置异常class AppError(Exception):本项目所有业务异常的根。调用方只需捕获这一个类即可兜底。class ValidationError(AppError):输入不合法。class NotFoundError(AppError):资源不存在。class UpstreamError(AppError):依赖的外部系统不可用。class PermissionDeniedError(AppError):权限不足。配套三条纪律纪律一绝不写except: pass。裸except:会连KeyboardInterrupt、SystemExit一起吞掉用户按 CtrlC 都停不下来。即使换成except Exception:什么都不做的捕获依然是坏味道——它把一条本该送达的信息半路截杀了。至少要做一件事记录或者转换语义后重抛。纪律二区分「预期内的失败」与「预期外的 bug」。前者用自定义异常承载是正常的业务分支边界处翻译成用户能看懂的错误比如「库存不足」后者KeyError、AttributeError、TypeError这类说明代码有缺陷应当让它冒出来并配上完整堆栈而不是被同一段except一起吞成「操作失败」。很多团队的做法是在边界处留一个except Exception:兜底但兜底之后一定要logger.exception绝不能静默。纪律三异常层次要服务于调用方的决策。划分新异常类的唯一理由是「调用方需要区别对待」。如果两个异常在每一处except里都归到同一个分支那它们就该合并。常见坑点1. 用except: pass吞掉一切❌try: do_something()后面except: pass连KeyboardInterrupt都吞了。 ✅ 明确异常类型确实要兜底就写except Exception:并且至少logger.exception(...)记一笔或转换后重抛。2. 把整个函数体塞进一个try❌ 用一个try从函数第一行包到最后一行出了异常根本分不清是哪一步出的。 ✅ 只把真正可能抛出、且你打算处理的那几行放进try范围越小异常归属越清楚except里能做的事也越明确。3. 用logger.error代替logger.exception❌logger.error(读取失败)日志里只有一句话看不出在哪一行、因为什么崩的。 ✅ 在except块里用logger.exception(读取失败id%s, item_id)堆栈自动带上。4. 预先把日志字符串拼好❌logger.info(处理完成 str(n) 条)无论是否输出都要先拼一次内容里有%还可能二次格式化出错。 ✅ 写成logger.info(处理完成%s 条, n)交给日志模块延迟格式化。5. 在中间层捕获后返回None❌ 业务函数里except Exception: return None调用方拿到None只能靠猜还常常继续往下传。 ✅ 中间层不捕获让异常往上走必须在边界处转换时返回结构化的错误对象别用None当哨兵。6. 用异常做正常流程的主分派❌ 一个循环靠抛异常来退出正常路径也走except。 ✅ 正常分支用条件判断异常留给真正的例外情况。7. 边界处把堆栈返回给调用方❌ 接口里return str(traceback.format_exc())把文件路径、依赖版本都暴露出去。 ✅ 对外只给一个稳定的错误码与简短描述完整堆栈写进服务端日志。8. 兜底之外还继续执行❌ 捕获后记录一句日志然后接着往下跑用一个不完整的状态继续业务。 ✅ 想清楚「捕获之后这一层是否还能安全继续」不能就raise或返回明确的失败结果。总结主题结论EAFP / LBYLEAFP 更 Pythonic 且无竞态窗口失败是常态路径时 LBYL 可读性更好异常边界只在对外的入口、外部系统交界、致命点处理中间层不捕获捕获的理由只有「能做点有意义的事」才捕获日志logger.exception()只在except块里用参数化写%s兜底纪律不写except: pass兜底必须记录绝不能静默层次设计一个根异常 按「调用方是否需要区别对待」设子类工程级错误处理其实只有一句话在知道该怎么办的地方处理在知道该怎么记的地方记录在什么都不知道的地方让它往上走。把这三条摆正你会发现需要写try的地方比想象中少——而剩下的每一处都是真正需要它的地方。