作为一个写了多年Python的人我可以很直白地告诉你异常处理机制不是程序出错以后怎么擦屁股的补救措施而是一个优秀程序最核心的骨架。早些年我写代码总有一种迷之自信觉得自己写的逻辑一定对try/except能省则省结果上了生产环境以后被各种诡异的崩溃日志折磨到凌晨三点。后来我才慢慢意识到异常处理不是可有可无的安全带而是程序在运行过程中和你对话的语言。你把这门语言学好了程序哪里不舒服它会第一时间精确告诉你是哪个器官出了问题你学不好它只能整机直接崩溃给你看你拿到一个几百行的traceback一脸茫然。今天这篇内容我围绕Python的异常处理机制从最基础的异常体系、try/except/else/finally的配合方式到自定义异常、异常链再到我实际踩坑总结出来的一套异常处理设计经验完整地梳理一遍。不管你是在校学生、刚转行的开发者还是写了几年业务代码但从来没有系统地想过异常到底该怎么处理的人这篇都能给你一些可以马上用起来的思路。1. 异常不是bug是程序在给你发信号很多人第一次接触异常的时候本能地觉得异常就是程序出错了是坏东西。这种理解不能说全错但它会严重限制你的处理水平。我更愿意把异常理解为一种信号机制程序在运行过程中遇到了它自己解决不了的情况于是向调用它的上层抛出信号告诉上层我这里出事了你看怎么处理。程序只在你不处理信号的时候才会终止崩溃如果你正确地捕获并处理了信号程序完全可以继续往下走。1.1 我为什么把异常处理当作功能的一部分我见过太多只在求稳阶段才想起来补try/except的代码。比如接口调用外部服务先在主流程里写了一大堆业务逻辑等到测试发现请求第三方超时会导致整个接口500才在代码外面随便包一层try/except然后打印一句话就算完事。这种思路把异常处理当成了事后补丁结果往往是异常被吞掉了业务数据悄悄丢了一截但系统看起来还在正常跑。真正靠谱的做法是把异常处理当作功能需求的一部分在设计阶段就开始思考每个函数、每个模块在什么情况下会抛出什么异常以及这些异常应该在哪个层级处理。比如用户传入了非法的JSON字符串这个异常必须在入口处被捕获转换成400/422这种对外响应而数据库连接池耗尽就必须向上抛触发熔断和告警而不是在底层悄悄吞掉。这样程序才不是一团碰运气才能跑通的代码而是一个对可能发生的故障有明确预案的系统。1.2 异常体系基础BaseException与Exception的父子关系Python的异常体系是一棵继承树所有异常都继承自BaseException。这里有一个新手特别容易忽略的点不是所有BaseException的子类都应该用except Exception去捕获。BaseException下面直接生出了两个大方向一类是SystemExit、KeyboardInterrupt、GeneratorExit它们并不是程序运行出错而是程序主动退出、用户按了CtrlC、生成器被关闭这类特殊情况另一类是Exception这才是我们在日常业务代码里99%需要关心的异常基类。像ValueError、TypeError、KeyError、IOError这些都挂在Exception下面。所以当你看到except Exception的时候你以为你在捕获所有错误其实你并没有捕获SystemExit和KeyboardInterrupt这类信号。这个设计是有意为之的某个异常是否终止程序应该由代码语义决定而不是被一段随意的try/except拦腰截断。1.3 常见异常类速查表我整理了一份平时出现频率最高的异常速查表方便你写代码的时候做个对照异常类型抛出时机典型场景ValueError传入参数类型正确但值非法int(abc)TypeError类型不匹配或操作不受支持len(123)KeyError字典中不存在该键d[not_exist]IndexError索引超出序列范围lst[100]AttributeError对象没有该属性或方法None.nameZeroDivisionError除以01 / 0FileNotFoundError文件不存在open(no.txt)PermissionError权限不足打开没有权限的文件TimeoutError操作超时请求外部服务超时json.JSONDecodeErrorJSON解析失败json.loads({bad})sqlite3.OperationalError数据库操作异常表不存在、约束冲突看这张表的时候你可能会发现一个很有意思的事绝大多数异常名称本身就描述了发生了什么问题所以我一直建议团队里的新人先学会读异常信息再去查文档而不是一看到traceback就慌。异常信息里有文件名、行号、具体的错误描述这些东西比任何日志都更直接。2. try/except/else/finally四个关键字到底该怎么配合Python的异常处理语法看起来很简单就是try、except、else、finally四个关键字。但越是看起来简单的语法越容易在真实代码里被用歪。我见过很多人的代码一个函数里套了七八层try/except看了半天都搞不清楚到底在捕获什么也有人把return写在了finally里面导致函数的返回值被意外覆盖。这个章节我仔细拆一下每个关键字的定位和它们之间的执行顺序。2.1 基本语法与执行顺序一个完整的异常处理块长这样try: # 可能出问题的代码 risky_operation() except ValueError: # 捕获特定的异常类型 handle_value_error() except (TypeError, KeyError) as e: # 同时捕获多种异常 handle_other_error(e) else: # 没有异常时执行的代码 after_success() finally: # 无论是否异常都会执行的代码 cleanup()很多人以为else和finally是一个东西其实执行顺序差异很大。try块里的代码执行时如果一切顺利先执行完try块再执行else块然后执行finally块如果try块里有异常抛出跳过else块如果匹配某个except就进入对应分支出处理处理完继续执行finally最后执行finally块如果没有任何一个except能匹配抛出的异常该异常保留到最后等finally执行完以后再往外抛。这个执行顺序非常重要。它意味着else块只能在没有异常发生时执行而finally块无论如何都会执行。既然这样那else到底有什么存在意义直接写在try里不也一样不一样这是下一节要说的关键。2.2 else的正确使用场景try里不该塞太多代码在我最早写代码的时候喜欢把一大段逻辑全塞进try块里然后过一个except挂那里感觉这样最保险。后来排查一个隐藏bug时发现问题恰恰就出在这try块太大里面很多行代码都可能抛异常我根本不知道except捕获的到底是哪一个异常于是掩盖了真正出问题的代码。else块的意义就在于它帮你把我想保护的代码和保护成功后要做的代码分离开来。举个例子读取并解析配置文件def load_config(file_path): try: with open(file_path) as f: content f.read() except FileNotFoundError: return get_default_config() else: return parse_config(content)这里try块只负责读取文件如果文件不存在就用默认配置兜底如果文件读取成功则进入else进行解析。parse_config里如果抛ValueError它不会被FileNotFoundError捕获而是原样往外抛这样错误来源就很清楚。如果把解析逻辑也放进try里一旦parse_config抛出ValueError你可能就会误以为它是读取文件的部分出了问题排查起来会绕很多圈子。所以说try块应该尽量精简只包围那些你预期可能抛出特定异常的最小范围。范围越大异常来源越模糊代码越难维护。2.3 finally的核心特点资源清理的兜底finally块的作用是不管发生什么都会执行这里面的代码。它最常见的用途就是释放资源、关闭连接、清理临时文件。一个典型的文件写入场景f None try: f open(output.txt, w) f.write(hello) except OSError: print(写入失败) finally: if f is not None: f.close()这里即使write操作抛出异常我们依然可以确保文件被关闭。如果你不用finally在except里关闭文件代码就会变得很难看因为异常处理分支越多重复关闭代码就越多。还有一个细节很多人不知道就算try块里写了returnfinally块里的代码依然会在return之前执行。如果finally里再写一个return它会覆盖前面try或except里的return结果。def demo(): try: return try里的返回值 finally: return finally里的返回值 print(demo()) # 输出 finally里的返回值这个行为会让新手很困惑所以我强调一句不要在finally块里写return不要在finally块里写return不要在finally块里写return。如果确实需要在结束前做一些清理动作直接把清理语句写进去就好不要试图在finally里返回值。2.4 一个完整的文件处理示例综合上面的要点我给出一个比较规范的文件处理示例也是我在生产环境里常用的写法def read_first_line(file_path): f None try: f open(file_path, r, encodingutf-8) return f.readline().strip() except FileNotFoundError: # 文件不存在时返回空字符串让调用方决定怎么处理 return except UnicodeDecodeError as e: # 编码问题很常见单独捕获并给出清晰提示 raise ValueError(f文件解码失败请检查文件编码: {file_path}) from e finally: if f is not None: f.close()这段代码里try只负责打开文件并读取第一行FileNotFoundError被单独处理UnicodeDecodeError被转换成语义更清晰的ValueError并保留原始异常链finally保证文件必定被关闭。这就是一个比较合理的异常处理块每一个关键字都有它的位置没有多余也没有缺失。3. 自定义异常与异常链让代码自己说出故障类型Python内置的异常类型有几十种但实际项目里还是经常会遇到内置异常表达不出来的场景。比如你写一个订单服务库存不足、余额不足、订单状态不允许修改这些其实都是业务异常但它们本质上都是业务规则不被满足如果你全部用ValueError或者RuntimeError往上抛调用方的代码就会变成一长串模糊的if判断可读性非常差。3.1 何时需要自定义异常我判断是否需要自定义异常一般看三个标准这个异常是否代表当前业务领域内一个独立且明确的错误语义调用方是否需要针对这个异常做区别于其他异常的处理这个异常是否可能在不同的函数和层级之间被传播需要一个统一的标识。如果一个错误只在当前函数内部处理用完就没了那完全没必要自定义异常但如果你希望把订单余额不足这个信息从底层一路传到最上层让接口层能准确返回402 Payment Required之类的响应那自定义异常就是最合适的方案。3.2 定义自定义异常的步骤自定义异常非常简单核心就是继承Exception并加上合适的构造函数来传递附加信息class OrderError(Exception): 订单业务异常基类 class InsufficientBalanceError(OrderError): 余额不足异常 def __init__(self, order_id, balance, required_amount): self.order_id order_id self.balance balance self.required_amount required_amount super().__init__(f订单 {order_id} 余额不足: 当前余额 {balance}需要 {required_amount})这样定义之后捕获方使用起来就非常清晰try: create_order(user_id, order_items) except InsufficientBalanceError as e: # 余额不足时可以引导用户充值并打印相关订单号 return {error: balance_not_enough, order_id: e.order_id} except OrderError: # 其他订单类错误统一兜底 return {error: order_failed}这里的关键是把自定义异常分出一个基类再在基类下面细化具体异常类型。这样调用方既可以对具体的InsufficientBalanceError做单独处理也可以用OrderError来兜住所有订单相关的错误。如果你直接让每个异常都继承Exception那调用方想统一处理订单异常时就只能写多个except重复代码维护起来很痛苦。3.3 异常链raise...from的妙用在实际项目里底层抛出的异常往往不是上层真正关心的异常。比如底层是一个数据库操作抛出了一个sqlite3.OperationalError但这个操作本质上是创建订单这个业务动作的一部分上层更希望看到的异常类型是OrderError而不是一个数据库底层异常。这时候就要用到raise...from。def create_order(user_id, order_items): try: save_order_to_db(user_id, order_items) except sqlite3.OperationalError as e: raise OrderError(f订单保存失败user_id{user_id}) from efrom e的作用是把原始异常挂在新异常的__cause__属性里这样在traceback里你既能看到OrderError又能看到它背后的sqlite3.OperationalError排查问题的时候信息不会丢失。这一点特别重要因为一旦你丢失了原始异常后面排查为什么订单保存失败就只能靠猜了。还有一种写法是raise...from None它会把异常链截断不显示原始异常。这个写法要谨慎使用只有当原始异常明确不敏感、完全不需要保留时我才建议这么写否则一律推荐保留异常链。3.4 实际项目中的异常分层说到这里我想分享一下我在稍大型项目里常用的异常分层方式。我会把异常分成三层第一层是基础设施异常比如数据库异常、网络异常、文件系统异常这一层尽量靠近底层捕获后在合适的地方立刻转换成更通用的类型避免业务逻辑层和数据库细节耦合。第二层是业务逻辑异常比如余额不足、商品不存在、操作权限不足。这一层是异常体系中最重要的部分它代表领域规则它的定义往往和业务需求一一对应。第三层是接口层异常这一层一般是把业务异常翻译成HTTP状态码或对外错误码比如余额不足对应402参数错误对应400。# 基础设施层 class StorageError(Exception): pass # 业务层 class DomainError(Exception): pass class InsufficientBalanceError(DomainError): pass class ProductNotFoundError(DomainError): pass # 接口层 def handle_error(exc): if isinstance(exc, InsufficientBalanceError): return 402, {code: INSUFFICIENT_BALANCE} if isinstance(exc, ProductNotFoundError): return 404, {code: PRODUCT_NOT_FOUND} return 500, {code: INTERNAL_ERROR}这种分层最大的好处是底层模块不需要关心上层HTTP返回什么它只需要把对应的业务异常抛出去上层模块也不需要关心数据库里具体发生了什么它只需要根据业务异常的类型返回配置好的状态码。整个系统的异常语义就变得非常清晰。4. 异常处理中那些看似合理实则危险的写法异常处理语法本身不复杂真正让人头疼的是那些看起来没毛病实际上埋了很多雷的写法。我在code review的时候几乎每个项目都能找出几处这些写法通常不会让程序立刻崩溃但会在特定条件下制造出非常隐蔽的问题。4.1 空except和炸弹式捕获最典型的问题写法就是这种try: do_something() except: pass空except会捕获包括KeyboardInterrupt、SystemExit在内的所有异常然后直接pass掉。这意味着用户按CtrlC想终止程序程序可能完全没有反应程序想要退出可能被静默拦截。更可怕的是真正的错误被吞掉之后你连日志都没有出了问题只能干瞪眼。即便你是这样写try: do_something() except Exception: pass看起来比except:好一点但它仍然是在无差别吞异常。程序里如果有一个KeyError、一个TypeError都会被这样糊弄过去。我见过一个同事排查了一下午的bug最后发现是这个空except在某处把关键异常吞掉了数据写入失败却没有报错导致后续统计全部失真。如果你真的确定这里出了任何异常都不影响主流程那也至少要记录一下日志比如except Exception as e: logger.warning(非关键步骤失败原因: %s, e)。程序可以继续跑但你事后至少还能查得到发生了什么。4.2 过窄与过宽异常捕获有些同学为了严谨只捕获自己预期的那一种异常。比如try: value int(user_input) except ValueError: return 请输入整数看起来没问题但如果user_input是一个Noneint(None)会抛出TypeError而TypeError没有被捕获程序直接崩溃。用户输入格式千奇百怪我们无法预料每一个可能的异常类型。所以在这种场景下捕获一个合理的基类可能比捕获单一类型更符合实际需求。反过来捕获太宽同样有问题try: result complex_calculation() except Exception: return None把一个大函数包在except Exception里一旦函数里任何一行出错返回值都是None。调用方拿到None以后还要再做一层空值判断等于把异常处理的负担又转移到了上层。我建议捕获异常时遵循一个原则能明确具体类型就明确具体类型如果某个函数在真实场景中可能抛出多种异常优先考虑把异常转换成一个更语义化的自定义异常重新抛出而不是笼统地except Exception。4.3 忽略异常和过度打印traceback有一种情况比较尴尬你知道这里可能会出错但不知道出了错以后该怎么处理于是先写一个except然后打印traceback感觉先记录一下后续再处理。结果这个后续永远不会到来因为print出来的traceback在日志系统里根本不会完整保存而且代码看起来像处理了错误实际上啥也没干。正确做法是如果暂时不知道如何处理至少用日志系统的exception方法记录完整的堆栈信息import logging logger logging.getLogger(__name__) try: do_something() except Exception: logger.exception(do_something 执行失败堆栈信息如下)logger.exception会在日志中输出完整的traceback并且带上你写的上下文信息。这样等你有空回过头来处理时还能通过日志定位到当时的完整现场。如果你用print输出到控制台之后就没有了等于白记。4.4 在except里抛新异常把原始信息弄丢这个问题我在3.3节提到过但因为它太常见我在这里再强调一遍。很多人会在except里直接raise一个新的异常不保留原始异常try: process_data() except ValueError as e: raise BusinessError(数据异常)这样的话一旦BusinessError被抛到上层你再想回溯到原始的ValueError时traceback里已经看不到了。正确的写法应该是try: process_data() except ValueError as e: raise BusinessError(数据异常) from e对我来说from e已经成了写异常处理时的一个默认习惯几乎每一条raise新异常的语句都会带上from。只有极少数不希望原始异常泄露给外部的场景比如不想暴露内部数据库细节才会考虑用from None。保留异常链是排查问题时最重要的案件线索千万别随随便便把它掐断。5. 一个典型的异常排查实战从崩溃日志到问题定位之前讲了这么多理论这个章节我用一个我真实的排查经历把它串起来。那是一个订单系统某天半夜监控突然报了一个接口错误率上升的告警但服务并没有完全挂掉只是客户在下单时偶尔会收到500。我拿到崩溃日志之后开始了异常排查的完整链路。5.1 场景描述与bug复现这个接口的流程大致是这样用户提交订单服务端先校验商品库存如果库存足够就插入订单记录然后扣减库存。崩溃日志里的关键信息如下Traceback (most recent call last): File order_service.py, line 210, in create_order create_order_record(...) ... sqlite3.IntegrityError: UNIQUE constraint failed: orders.order_no看到这个异常的第一反应很简单订单号产生了重复导致唯一约束冲突。真正的问题在于为什么会产生重复的订单号这就要沿着异常链往下挖了而不是简单地在create_order_record外面包一层重复重试就完事。5.2 逐层排查的完整链路我第一件事是去查订单号是怎么生成的。代码里写的是用一个时间戳加随机数的方式生成订单号格式大致是这样的def generate_order_no(): return time.strftime(%Y%m%d%H%M%S) str(random.randint(1000, 9999))这个订单号的生成逻辑在绝大多数情况下不会有问题熟悉Python的人马上能想到问题出在哪同一秒内如果生成两个订单时间戳完全一样而四位随机数的碰撞概率在并发量高的时候并不低。如果同时有两个请求进入两个订单号就有可能完全一致于是插入数据库时唯一约束就炸了。这不是异常处理本身的问题但异常处理给了我发现这个问题的关键线索。如果当初没有把sqlite3.IntegrityError映射成自定义异常也没有保留异常链我可能需要很久才能从一堆业务日志里定位到订单号生成逻辑的问题。修复方式很简单把订单号生成改成UUID、雪花ID或者用数据库自增序列。这个项目因为订单号还要用于外部对账不能直接上随机字符串最后改成日期数据库序列的组合保证在同一个业务日内唯一。5.3 修复方案与验证修复代码以后我没有急着上线先做了三个验证第一用高并发脚本模拟1000个同时下单的请求确认不再出现唯一约束冲突 第二检查数据库里是否还存在因为历史异常导致的不一致数据 第三看了异常日志和告警确认错误率下降到0。这个案例想说明的是异常处理机制不只是让你捕获错误、避免崩溃它还承担了一个非常重要的角色就是提供可用于根因分析的线索。如果我在代码里用了空except把IntegrityError吞掉那么这个并发问题可能会潜伏很久直到线上出现大量订单丢失才被察觉。异常信息越完整你的定位路径就越清晰。6. 异常处理设计的关键经验我踩过坑之后沉淀的几条原则文末这个章节我想聊一点更偏设计层面的东西。这些经验不是从文档里看来的是我在多个项目里踩坑、复盘、重构之后慢慢沉淀下来的。6.1 异常粒度与调用层级的平衡设计异常处理时我听到最多的一个困惑是我到底应该在哪里捕获异常我的基本原则是底层不吞异常上层不露细节。底层函数如果遇到了它处理不了的问题应该大胆地往上抛甚至可以转换成语义更清晰的异常再抛但不要在本层就把异常吞掉因为本层往往缺乏足够的上下文来决定这个错误对用户意味着什么。上层接口则应该在收到异常时根据异常类型决定怎么反馈给用户但尽量不要把底层的堆栈细节直接暴露给调用方。拿一个三层架构举例数据访问层抛sqlite3.OperationalError、ValueError或者转换成StorageError业务逻辑层捕获底层异常校验业务规则抛DomainError接口层捕获DomainError返回对应的错误码和提示信息。每一层只关心自己这一层需要关心的异常底层异常不会穿过所有层直接冒到接口层接口层也不用去理解数据库异常的含义。6.2 日志与监控的配合不要让异常只出现在控制台异常处理不止是代码层面的try/except它和日志系统、监控系统是强绑定的。我见过太多项目程序里try/except写得满满当当但异常处理分支里全是空实现或者pass导致线上出问题的时候连一条日志都找不到。所以我建议在项目里养成几个习惯每个except分支至少要记录一条日志说明发生了哪类异常、发生在什么场景、影响范围有多大对于不应该发生的异常比如逻辑错误、断言失败应该用logger.exception记录完整堆栈并接入告警对于可以预期的业务异常比如余额不足、商品不存在可以用logger.info或logger.warning记录上下文不用堆栈因为这些是业务分支不是系统错误在关键路径上比如支付、下单、数据导入我还会额外打一条结果日志记录成功/失败、耗时、关键参数这样排障时能快速画出一条完整的调用链。很多时候你缺的不是异常类型而是异常的上下文。一条带参数、带当前用户、带业务ID的日志比光秃秃的traceback值钱十倍。6.3 关于到底要不要处理这个异常的最后一个建议我在code review时经常问别人一个问题这个异常发生后你的程序应该做什么如果对方答不上来那这个异常处理大概率就是在瞎写。异常处理的本质是你在提前替程序回答一个问题当情况A发生时程序该怎么走当情况B发生时程序该怎么走。如果程序里没有这些预案那么当意外真的发生时运行时的表现就是崩溃、卡死、数据不一致。我见过有些项目为了防止崩溃把大半个业务逻辑包在try/except Exception里然后返回一个空对象结果用户看到的是操作成功但数据没写入这种处理方式比直接崩溃更可怕。从我个人的经验来看最理想的异常处理状态是每一个异常被抛出时都像一个训练有素的员工在向你汇报问题——它不仅告诉你出错了还能告诉你哪里出错、为什么出错、当前上下文是什么、有没有补救空间。达到这个状态之后你再回头看那些曾经让你头疼的崩溃日志就会发现它们其实都是很有用的线索而不是单纯的坏消息。
Python异常处理完全指南：从try/except到自定义异常与工程实践
作为一个写了多年Python的人我可以很直白地告诉你异常处理机制不是程序出错以后怎么擦屁股的补救措施而是一个优秀程序最核心的骨架。早些年我写代码总有一种迷之自信觉得自己写的逻辑一定对try/except能省则省结果上了生产环境以后被各种诡异的崩溃日志折磨到凌晨三点。后来我才慢慢意识到异常处理不是可有可无的安全带而是程序在运行过程中和你对话的语言。你把这门语言学好了程序哪里不舒服它会第一时间精确告诉你是哪个器官出了问题你学不好它只能整机直接崩溃给你看你拿到一个几百行的traceback一脸茫然。今天这篇内容我围绕Python的异常处理机制从最基础的异常体系、try/except/else/finally的配合方式到自定义异常、异常链再到我实际踩坑总结出来的一套异常处理设计经验完整地梳理一遍。不管你是在校学生、刚转行的开发者还是写了几年业务代码但从来没有系统地想过异常到底该怎么处理的人这篇都能给你一些可以马上用起来的思路。1. 异常不是bug是程序在给你发信号很多人第一次接触异常的时候本能地觉得异常就是程序出错了是坏东西。这种理解不能说全错但它会严重限制你的处理水平。我更愿意把异常理解为一种信号机制程序在运行过程中遇到了它自己解决不了的情况于是向调用它的上层抛出信号告诉上层我这里出事了你看怎么处理。程序只在你不处理信号的时候才会终止崩溃如果你正确地捕获并处理了信号程序完全可以继续往下走。1.1 我为什么把异常处理当作功能的一部分我见过太多只在求稳阶段才想起来补try/except的代码。比如接口调用外部服务先在主流程里写了一大堆业务逻辑等到测试发现请求第三方超时会导致整个接口500才在代码外面随便包一层try/except然后打印一句话就算完事。这种思路把异常处理当成了事后补丁结果往往是异常被吞掉了业务数据悄悄丢了一截但系统看起来还在正常跑。真正靠谱的做法是把异常处理当作功能需求的一部分在设计阶段就开始思考每个函数、每个模块在什么情况下会抛出什么异常以及这些异常应该在哪个层级处理。比如用户传入了非法的JSON字符串这个异常必须在入口处被捕获转换成400/422这种对外响应而数据库连接池耗尽就必须向上抛触发熔断和告警而不是在底层悄悄吞掉。这样程序才不是一团碰运气才能跑通的代码而是一个对可能发生的故障有明确预案的系统。1.2 异常体系基础BaseException与Exception的父子关系Python的异常体系是一棵继承树所有异常都继承自BaseException。这里有一个新手特别容易忽略的点不是所有BaseException的子类都应该用except Exception去捕获。BaseException下面直接生出了两个大方向一类是SystemExit、KeyboardInterrupt、GeneratorExit它们并不是程序运行出错而是程序主动退出、用户按了CtrlC、生成器被关闭这类特殊情况另一类是Exception这才是我们在日常业务代码里99%需要关心的异常基类。像ValueError、TypeError、KeyError、IOError这些都挂在Exception下面。所以当你看到except Exception的时候你以为你在捕获所有错误其实你并没有捕获SystemExit和KeyboardInterrupt这类信号。这个设计是有意为之的某个异常是否终止程序应该由代码语义决定而不是被一段随意的try/except拦腰截断。1.3 常见异常类速查表我整理了一份平时出现频率最高的异常速查表方便你写代码的时候做个对照异常类型抛出时机典型场景ValueError传入参数类型正确但值非法int(abc)TypeError类型不匹配或操作不受支持len(123)KeyError字典中不存在该键d[not_exist]IndexError索引超出序列范围lst[100]AttributeError对象没有该属性或方法None.nameZeroDivisionError除以01 / 0FileNotFoundError文件不存在open(no.txt)PermissionError权限不足打开没有权限的文件TimeoutError操作超时请求外部服务超时json.JSONDecodeErrorJSON解析失败json.loads({bad})sqlite3.OperationalError数据库操作异常表不存在、约束冲突看这张表的时候你可能会发现一个很有意思的事绝大多数异常名称本身就描述了发生了什么问题所以我一直建议团队里的新人先学会读异常信息再去查文档而不是一看到traceback就慌。异常信息里有文件名、行号、具体的错误描述这些东西比任何日志都更直接。2. try/except/else/finally四个关键字到底该怎么配合Python的异常处理语法看起来很简单就是try、except、else、finally四个关键字。但越是看起来简单的语法越容易在真实代码里被用歪。我见过很多人的代码一个函数里套了七八层try/except看了半天都搞不清楚到底在捕获什么也有人把return写在了finally里面导致函数的返回值被意外覆盖。这个章节我仔细拆一下每个关键字的定位和它们之间的执行顺序。2.1 基本语法与执行顺序一个完整的异常处理块长这样try: # 可能出问题的代码 risky_operation() except ValueError: # 捕获特定的异常类型 handle_value_error() except (TypeError, KeyError) as e: # 同时捕获多种异常 handle_other_error(e) else: # 没有异常时执行的代码 after_success() finally: # 无论是否异常都会执行的代码 cleanup()很多人以为else和finally是一个东西其实执行顺序差异很大。try块里的代码执行时如果一切顺利先执行完try块再执行else块然后执行finally块如果try块里有异常抛出跳过else块如果匹配某个except就进入对应分支出处理处理完继续执行finally最后执行finally块如果没有任何一个except能匹配抛出的异常该异常保留到最后等finally执行完以后再往外抛。这个执行顺序非常重要。它意味着else块只能在没有异常发生时执行而finally块无论如何都会执行。既然这样那else到底有什么存在意义直接写在try里不也一样不一样这是下一节要说的关键。2.2 else的正确使用场景try里不该塞太多代码在我最早写代码的时候喜欢把一大段逻辑全塞进try块里然后过一个except挂那里感觉这样最保险。后来排查一个隐藏bug时发现问题恰恰就出在这try块太大里面很多行代码都可能抛异常我根本不知道except捕获的到底是哪一个异常于是掩盖了真正出问题的代码。else块的意义就在于它帮你把我想保护的代码和保护成功后要做的代码分离开来。举个例子读取并解析配置文件def load_config(file_path): try: with open(file_path) as f: content f.read() except FileNotFoundError: return get_default_config() else: return parse_config(content)这里try块只负责读取文件如果文件不存在就用默认配置兜底如果文件读取成功则进入else进行解析。parse_config里如果抛ValueError它不会被FileNotFoundError捕获而是原样往外抛这样错误来源就很清楚。如果把解析逻辑也放进try里一旦parse_config抛出ValueError你可能就会误以为它是读取文件的部分出了问题排查起来会绕很多圈子。所以说try块应该尽量精简只包围那些你预期可能抛出特定异常的最小范围。范围越大异常来源越模糊代码越难维护。2.3 finally的核心特点资源清理的兜底finally块的作用是不管发生什么都会执行这里面的代码。它最常见的用途就是释放资源、关闭连接、清理临时文件。一个典型的文件写入场景f None try: f open(output.txt, w) f.write(hello) except OSError: print(写入失败) finally: if f is not None: f.close()这里即使write操作抛出异常我们依然可以确保文件被关闭。如果你不用finally在except里关闭文件代码就会变得很难看因为异常处理分支越多重复关闭代码就越多。还有一个细节很多人不知道就算try块里写了returnfinally块里的代码依然会在return之前执行。如果finally里再写一个return它会覆盖前面try或except里的return结果。def demo(): try: return try里的返回值 finally: return finally里的返回值 print(demo()) # 输出 finally里的返回值这个行为会让新手很困惑所以我强调一句不要在finally块里写return不要在finally块里写return不要在finally块里写return。如果确实需要在结束前做一些清理动作直接把清理语句写进去就好不要试图在finally里返回值。2.4 一个完整的文件处理示例综合上面的要点我给出一个比较规范的文件处理示例也是我在生产环境里常用的写法def read_first_line(file_path): f None try: f open(file_path, r, encodingutf-8) return f.readline().strip() except FileNotFoundError: # 文件不存在时返回空字符串让调用方决定怎么处理 return except UnicodeDecodeError as e: # 编码问题很常见单独捕获并给出清晰提示 raise ValueError(f文件解码失败请检查文件编码: {file_path}) from e finally: if f is not None: f.close()这段代码里try只负责打开文件并读取第一行FileNotFoundError被单独处理UnicodeDecodeError被转换成语义更清晰的ValueError并保留原始异常链finally保证文件必定被关闭。这就是一个比较合理的异常处理块每一个关键字都有它的位置没有多余也没有缺失。3. 自定义异常与异常链让代码自己说出故障类型Python内置的异常类型有几十种但实际项目里还是经常会遇到内置异常表达不出来的场景。比如你写一个订单服务库存不足、余额不足、订单状态不允许修改这些其实都是业务异常但它们本质上都是业务规则不被满足如果你全部用ValueError或者RuntimeError往上抛调用方的代码就会变成一长串模糊的if判断可读性非常差。3.1 何时需要自定义异常我判断是否需要自定义异常一般看三个标准这个异常是否代表当前业务领域内一个独立且明确的错误语义调用方是否需要针对这个异常做区别于其他异常的处理这个异常是否可能在不同的函数和层级之间被传播需要一个统一的标识。如果一个错误只在当前函数内部处理用完就没了那完全没必要自定义异常但如果你希望把订单余额不足这个信息从底层一路传到最上层让接口层能准确返回402 Payment Required之类的响应那自定义异常就是最合适的方案。3.2 定义自定义异常的步骤自定义异常非常简单核心就是继承Exception并加上合适的构造函数来传递附加信息class OrderError(Exception): 订单业务异常基类 class InsufficientBalanceError(OrderError): 余额不足异常 def __init__(self, order_id, balance, required_amount): self.order_id order_id self.balance balance self.required_amount required_amount super().__init__(f订单 {order_id} 余额不足: 当前余额 {balance}需要 {required_amount})这样定义之后捕获方使用起来就非常清晰try: create_order(user_id, order_items) except InsufficientBalanceError as e: # 余额不足时可以引导用户充值并打印相关订单号 return {error: balance_not_enough, order_id: e.order_id} except OrderError: # 其他订单类错误统一兜底 return {error: order_failed}这里的关键是把自定义异常分出一个基类再在基类下面细化具体异常类型。这样调用方既可以对具体的InsufficientBalanceError做单独处理也可以用OrderError来兜住所有订单相关的错误。如果你直接让每个异常都继承Exception那调用方想统一处理订单异常时就只能写多个except重复代码维护起来很痛苦。3.3 异常链raise...from的妙用在实际项目里底层抛出的异常往往不是上层真正关心的异常。比如底层是一个数据库操作抛出了一个sqlite3.OperationalError但这个操作本质上是创建订单这个业务动作的一部分上层更希望看到的异常类型是OrderError而不是一个数据库底层异常。这时候就要用到raise...from。def create_order(user_id, order_items): try: save_order_to_db(user_id, order_items) except sqlite3.OperationalError as e: raise OrderError(f订单保存失败user_id{user_id}) from efrom e的作用是把原始异常挂在新异常的__cause__属性里这样在traceback里你既能看到OrderError又能看到它背后的sqlite3.OperationalError排查问题的时候信息不会丢失。这一点特别重要因为一旦你丢失了原始异常后面排查为什么订单保存失败就只能靠猜了。还有一种写法是raise...from None它会把异常链截断不显示原始异常。这个写法要谨慎使用只有当原始异常明确不敏感、完全不需要保留时我才建议这么写否则一律推荐保留异常链。3.4 实际项目中的异常分层说到这里我想分享一下我在稍大型项目里常用的异常分层方式。我会把异常分成三层第一层是基础设施异常比如数据库异常、网络异常、文件系统异常这一层尽量靠近底层捕获后在合适的地方立刻转换成更通用的类型避免业务逻辑层和数据库细节耦合。第二层是业务逻辑异常比如余额不足、商品不存在、操作权限不足。这一层是异常体系中最重要的部分它代表领域规则它的定义往往和业务需求一一对应。第三层是接口层异常这一层一般是把业务异常翻译成HTTP状态码或对外错误码比如余额不足对应402参数错误对应400。# 基础设施层 class StorageError(Exception): pass # 业务层 class DomainError(Exception): pass class InsufficientBalanceError(DomainError): pass class ProductNotFoundError(DomainError): pass # 接口层 def handle_error(exc): if isinstance(exc, InsufficientBalanceError): return 402, {code: INSUFFICIENT_BALANCE} if isinstance(exc, ProductNotFoundError): return 404, {code: PRODUCT_NOT_FOUND} return 500, {code: INTERNAL_ERROR}这种分层最大的好处是底层模块不需要关心上层HTTP返回什么它只需要把对应的业务异常抛出去上层模块也不需要关心数据库里具体发生了什么它只需要根据业务异常的类型返回配置好的状态码。整个系统的异常语义就变得非常清晰。4. 异常处理中那些看似合理实则危险的写法异常处理语法本身不复杂真正让人头疼的是那些看起来没毛病实际上埋了很多雷的写法。我在code review的时候几乎每个项目都能找出几处这些写法通常不会让程序立刻崩溃但会在特定条件下制造出非常隐蔽的问题。4.1 空except和炸弹式捕获最典型的问题写法就是这种try: do_something() except: pass空except会捕获包括KeyboardInterrupt、SystemExit在内的所有异常然后直接pass掉。这意味着用户按CtrlC想终止程序程序可能完全没有反应程序想要退出可能被静默拦截。更可怕的是真正的错误被吞掉之后你连日志都没有出了问题只能干瞪眼。即便你是这样写try: do_something() except Exception: pass看起来比except:好一点但它仍然是在无差别吞异常。程序里如果有一个KeyError、一个TypeError都会被这样糊弄过去。我见过一个同事排查了一下午的bug最后发现是这个空except在某处把关键异常吞掉了数据写入失败却没有报错导致后续统计全部失真。如果你真的确定这里出了任何异常都不影响主流程那也至少要记录一下日志比如except Exception as e: logger.warning(非关键步骤失败原因: %s, e)。程序可以继续跑但你事后至少还能查得到发生了什么。4.2 过窄与过宽异常捕获有些同学为了严谨只捕获自己预期的那一种异常。比如try: value int(user_input) except ValueError: return 请输入整数看起来没问题但如果user_input是一个Noneint(None)会抛出TypeError而TypeError没有被捕获程序直接崩溃。用户输入格式千奇百怪我们无法预料每一个可能的异常类型。所以在这种场景下捕获一个合理的基类可能比捕获单一类型更符合实际需求。反过来捕获太宽同样有问题try: result complex_calculation() except Exception: return None把一个大函数包在except Exception里一旦函数里任何一行出错返回值都是None。调用方拿到None以后还要再做一层空值判断等于把异常处理的负担又转移到了上层。我建议捕获异常时遵循一个原则能明确具体类型就明确具体类型如果某个函数在真实场景中可能抛出多种异常优先考虑把异常转换成一个更语义化的自定义异常重新抛出而不是笼统地except Exception。4.3 忽略异常和过度打印traceback有一种情况比较尴尬你知道这里可能会出错但不知道出了错以后该怎么处理于是先写一个except然后打印traceback感觉先记录一下后续再处理。结果这个后续永远不会到来因为print出来的traceback在日志系统里根本不会完整保存而且代码看起来像处理了错误实际上啥也没干。正确做法是如果暂时不知道如何处理至少用日志系统的exception方法记录完整的堆栈信息import logging logger logging.getLogger(__name__) try: do_something() except Exception: logger.exception(do_something 执行失败堆栈信息如下)logger.exception会在日志中输出完整的traceback并且带上你写的上下文信息。这样等你有空回过头来处理时还能通过日志定位到当时的完整现场。如果你用print输出到控制台之后就没有了等于白记。4.4 在except里抛新异常把原始信息弄丢这个问题我在3.3节提到过但因为它太常见我在这里再强调一遍。很多人会在except里直接raise一个新的异常不保留原始异常try: process_data() except ValueError as e: raise BusinessError(数据异常)这样的话一旦BusinessError被抛到上层你再想回溯到原始的ValueError时traceback里已经看不到了。正确的写法应该是try: process_data() except ValueError as e: raise BusinessError(数据异常) from e对我来说from e已经成了写异常处理时的一个默认习惯几乎每一条raise新异常的语句都会带上from。只有极少数不希望原始异常泄露给外部的场景比如不想暴露内部数据库细节才会考虑用from None。保留异常链是排查问题时最重要的案件线索千万别随随便便把它掐断。5. 一个典型的异常排查实战从崩溃日志到问题定位之前讲了这么多理论这个章节我用一个我真实的排查经历把它串起来。那是一个订单系统某天半夜监控突然报了一个接口错误率上升的告警但服务并没有完全挂掉只是客户在下单时偶尔会收到500。我拿到崩溃日志之后开始了异常排查的完整链路。5.1 场景描述与bug复现这个接口的流程大致是这样用户提交订单服务端先校验商品库存如果库存足够就插入订单记录然后扣减库存。崩溃日志里的关键信息如下Traceback (most recent call last): File order_service.py, line 210, in create_order create_order_record(...) ... sqlite3.IntegrityError: UNIQUE constraint failed: orders.order_no看到这个异常的第一反应很简单订单号产生了重复导致唯一约束冲突。真正的问题在于为什么会产生重复的订单号这就要沿着异常链往下挖了而不是简单地在create_order_record外面包一层重复重试就完事。5.2 逐层排查的完整链路我第一件事是去查订单号是怎么生成的。代码里写的是用一个时间戳加随机数的方式生成订单号格式大致是这样的def generate_order_no(): return time.strftime(%Y%m%d%H%M%S) str(random.randint(1000, 9999))这个订单号的生成逻辑在绝大多数情况下不会有问题熟悉Python的人马上能想到问题出在哪同一秒内如果生成两个订单时间戳完全一样而四位随机数的碰撞概率在并发量高的时候并不低。如果同时有两个请求进入两个订单号就有可能完全一致于是插入数据库时唯一约束就炸了。这不是异常处理本身的问题但异常处理给了我发现这个问题的关键线索。如果当初没有把sqlite3.IntegrityError映射成自定义异常也没有保留异常链我可能需要很久才能从一堆业务日志里定位到订单号生成逻辑的问题。修复方式很简单把订单号生成改成UUID、雪花ID或者用数据库自增序列。这个项目因为订单号还要用于外部对账不能直接上随机字符串最后改成日期数据库序列的组合保证在同一个业务日内唯一。5.3 修复方案与验证修复代码以后我没有急着上线先做了三个验证第一用高并发脚本模拟1000个同时下单的请求确认不再出现唯一约束冲突 第二检查数据库里是否还存在因为历史异常导致的不一致数据 第三看了异常日志和告警确认错误率下降到0。这个案例想说明的是异常处理机制不只是让你捕获错误、避免崩溃它还承担了一个非常重要的角色就是提供可用于根因分析的线索。如果我在代码里用了空except把IntegrityError吞掉那么这个并发问题可能会潜伏很久直到线上出现大量订单丢失才被察觉。异常信息越完整你的定位路径就越清晰。6. 异常处理设计的关键经验我踩过坑之后沉淀的几条原则文末这个章节我想聊一点更偏设计层面的东西。这些经验不是从文档里看来的是我在多个项目里踩坑、复盘、重构之后慢慢沉淀下来的。6.1 异常粒度与调用层级的平衡设计异常处理时我听到最多的一个困惑是我到底应该在哪里捕获异常我的基本原则是底层不吞异常上层不露细节。底层函数如果遇到了它处理不了的问题应该大胆地往上抛甚至可以转换成语义更清晰的异常再抛但不要在本层就把异常吞掉因为本层往往缺乏足够的上下文来决定这个错误对用户意味着什么。上层接口则应该在收到异常时根据异常类型决定怎么反馈给用户但尽量不要把底层的堆栈细节直接暴露给调用方。拿一个三层架构举例数据访问层抛sqlite3.OperationalError、ValueError或者转换成StorageError业务逻辑层捕获底层异常校验业务规则抛DomainError接口层捕获DomainError返回对应的错误码和提示信息。每一层只关心自己这一层需要关心的异常底层异常不会穿过所有层直接冒到接口层接口层也不用去理解数据库异常的含义。6.2 日志与监控的配合不要让异常只出现在控制台异常处理不止是代码层面的try/except它和日志系统、监控系统是强绑定的。我见过太多项目程序里try/except写得满满当当但异常处理分支里全是空实现或者pass导致线上出问题的时候连一条日志都找不到。所以我建议在项目里养成几个习惯每个except分支至少要记录一条日志说明发生了哪类异常、发生在什么场景、影响范围有多大对于不应该发生的异常比如逻辑错误、断言失败应该用logger.exception记录完整堆栈并接入告警对于可以预期的业务异常比如余额不足、商品不存在可以用logger.info或logger.warning记录上下文不用堆栈因为这些是业务分支不是系统错误在关键路径上比如支付、下单、数据导入我还会额外打一条结果日志记录成功/失败、耗时、关键参数这样排障时能快速画出一条完整的调用链。很多时候你缺的不是异常类型而是异常的上下文。一条带参数、带当前用户、带业务ID的日志比光秃秃的traceback值钱十倍。6.3 关于到底要不要处理这个异常的最后一个建议我在code review时经常问别人一个问题这个异常发生后你的程序应该做什么如果对方答不上来那这个异常处理大概率就是在瞎写。异常处理的本质是你在提前替程序回答一个问题当情况A发生时程序该怎么走当情况B发生时程序该怎么走。如果程序里没有这些预案那么当意外真的发生时运行时的表现就是崩溃、卡死、数据不一致。我见过有些项目为了防止崩溃把大半个业务逻辑包在try/except Exception里然后返回一个空对象结果用户看到的是操作成功但数据没写入这种处理方式比直接崩溃更可怕。从我个人的经验来看最理想的异常处理状态是每一个异常被抛出时都像一个训练有素的员工在向你汇报问题——它不仅告诉你出错了还能告诉你哪里出错、为什么出错、当前上下文是什么、有没有补救空间。达到这个状态之后你再回头看那些曾经让你头疼的崩溃日志就会发现它们其实都是很有用的线索而不是单纯的坏消息。