python异常处理应精准捕获具体异常、避免裸except，善用else/finally分离逻辑与清理，设计语义明确的自定义异常，并通过异常链保留根因。
Python异常处理不是为了掩盖错误，而是让程序在出错时仍能可控、可读、可维护地响应。关键在于：只捕获你准备处理的异常，不吞掉有用的错误信息，用自定义异常明确业务语义。
精准捕获，避免裸except
使用空 except: 或 except Exception: 会隐藏真正的错误（比如 KeyboardInterrupt、SystemExit），干扰调试，还可能掩盖逻辑缺陷。
- 明确写出要处理的具体异常类型，例如 FileNotFoundError、ValueError、requests.exceptions.Timeout
- 如果必须兜底，用 except Exception as e: 并至少记录日志，再考虑是否重新抛出
- 绝不在生产代码中写 except: pass —— 这等于主动丢弃故障信号
合理使用else和finally
else 块在 try 中没发生异常时执行，适合放不希望被异常中断、但又依赖前序成功执行的逻辑；finally 则保证清理动作一定运行，无论是否异常。
- 把“成功后才做”的操作（如发送通知、更新状态）放进 else，避免和异常处理逻辑混在一起
- 用 finally 关闭文件、释放锁、断开数据库连接等——即使 return 或 raise 出现在 try/else 中也生效
- 注意：finally 中若抛出新异常，会覆盖原异常；若需保留原始异常，可用 raise ... from e
设计有意义的自定义异常
内置异常无法表达业务规则。自定义异常应体现领域意图，便于调用方识别和分类处理。
立即学习“Python免费学习笔记（深入）”；
- 继承 Exception（非 BaseException），命名以 Error 结尾（如 InsufficientBalanceError）
- 在 __init__ 中接收必要参数并构造清晰提示，例如用户ID、余额、阈值
- 可添加属性（如 .user_id、.code）供上层提取结构化信息，避免字符串解析
- 避免为每个小逻辑都建新异常类，按错误语义分组（如所有支付失败归到 PaymentError 及其子类）
异常链与上下文传递
当在处理一个异常时又发生另一个异常，用 raise ... from original_exc 显式建立因果关系，保留原始堆栈。
- 不要简单 raise new_exc，否则丢失根因；也不要用 raise new_exc from None 除非刻意屏蔽源头
- 在日志中打印异常时，用 traceback.format_exception() 或结构化日志库（如 structlog）完整输出链式信息
- 跨服务调用时，可在自定义异常中封装原始异常类型、消息、关键字段，方便下游诊断
不复杂但容易忽略。真正健壮的异常处理，藏在对每种错误“是否该捕获”“由谁处理”“如何表达”的持续判断里。
