python异常需带上下文：拼接关键变量、用raise...from保留异常链、分小类自定义异常、用logging.exception()记录完整traceback，确保错误信息为人可读且可诊断。
异常信息里不带上下文等于没抛
Python 默认的 Exception 错误信息只包含类型和消息字符串，没有调用时的变量值、输入参数或状态快照，排查时得反复加 print 或进 debugger。这不是代码写得不够“规范”，是没把异常当诊断接口用。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 在
raise前主动拼接关键变量，比如：raise ValueError(f"invalid timeout={timeout}, must be > 0") - 避免裸
raise（即原样重抛），除非你确定上层已补充足够上下文；否则至少补一句说明场景，如：raise ValueError(f"failed to parse {raw_data!r} as JSON") - 对可能被多处调用的函数，在入口处做参数校验并提前报错，比让深层逻辑崩了再回溯更省时间
用 raise ... from 保留原始异常链
捕获后重新抛出时直接 raise new_exc 会丢掉原始 traceback，尤其在封装底层库（如 requests、sqlite3）时，根本看不出是网络超时还是 SQL 语法错。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 一律用
raise CustomError("...") from e，其中e是捕获到的原始异常 - 如果想抑制原始异常（极少数情况），显式写
raise NewError(...) from None，避免意外掩盖问题 - 注意：
from None后无法通过__cause__访问原始异常，但__context__还在——除非你也手动清空它
自定义异常类别要窄，消息模板要稳
所有错误都继承 Exception 或全扔进 RuntimeError，会让上层 except 无法精准处理；而每次抛异常都手拼字符串，又会导致日志里出现大量相似但无法正则匹配的变体。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 按错误性质分小类：比如
ConfigLoadError、NetworkTimeoutError、ValidationError，不要用AppError一锅端 - 在异常类的
__init__里固定格式化逻辑，例如：super().__init__(f"config {path} missing required key: {key}") - 避免在消息里拼接可能含敏感信息的变量（如密码、token），宁可留占位符或打码：
f"user_id={user_id[:4]}..."
logging.exception() 不等于 print(e)
很多人用 print(e) 或 str(e) 记日志，结果只看到一行消息，没有 traceback，也没法关联请求 ID 或线程名。这相当于把 X 光片撕掉，只留诊断结论。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 捕获异常后，优先用
logging.error("something went wrong", exc_info=True)或简写logging.exception("...") - 如果用了结构化日志（如
structlog），确保exc_info被正确提取为字段，而不是塞进 message 字符串里 - 别在
finally或装饰器里无差别logging.exception()—— 那里可能根本没异常，或者异常已被处理，反而污染日志
最常被忽略的一点：异常信息不是写给机器看的，是写给人看的。但人读得快不快，取决于你有没有把「当时发生了什么」和「为什么不能继续」压缩进同一句话里，而不是逼他去翻三份日志、查两个配置、再猜一次数据流向。
