该用 raise ... from 而不是裸 raise 的情况是：当原始异常被拦截后仍需保留其上下文（如日志溯源、调试查看完整调用链），同时抛出更贴近业务语义的新异常时；裸 raise 会丢失原始 traceback，导致底层失败原因难以定位。
什么时候该用 raise ... from 而不是裸 raise
当原始异常被拦截后，你仍想保留它作为上下文（比如日志溯源、调试时看到完整调用链），同时抛出一个更贴近业务语义的新异常时，必须用 raise ... from。裸 raise 会抹掉原始异常的 traceback，只剩新异常——这会让定位底层失败原因变得困难。
典型场景：数据库连接失败后，你不该只抛 ConnectionError，而应包装成 UserNotFoundError 并保留原始 psycopg2.OperationalError 的堆栈。
- 原始异常是底层依赖抛出的（如 requests、sqlalchemy、json.loads）
- 你想在上层定义领域异常（如
InvalidOrderStateError），但又不想丢掉原始错误细节 - 测试中需要断言异常链（
exc.__cause__或exc.__context__）
raise from 和 raise ... from None 的区别在哪
raise NewError() from OriginalError 会把 OriginalError 设为 NewError.__cause__，Python 打印时显示 “The above exception was the direct cause of the following exception”。
raise NewError() from None 则显式切断异常链，NewError.__cause__ 为 None，但原始异常仍保留在 __context__（除非被抑制）。这适用于你明确不想暴露底层实现细节的场合，比如封装第三方 SDK 时隐藏内部 HTTP 错误。
立即学习“Python免费学习笔记（深入）”；
- 默认
raise NewError() from OriginalError→__cause__非空，traceback 显示双段错误 -
raise NewError() from None→__cause__为None，避免泄露无关技术细节 - 不要混用：
raise NewError() from exc后再raise（无 from），会导致__cause__被覆盖为None
在类方法里封装异常链的常见写法
别在每个方法里重复写 try/except/raise from。把异常转换逻辑抽到工具函数或基类中，保持一致性。
例如定义一个 raise_as 工具函数：
def raise_as(exc: Exception, new_exc_class: type, message: str = ""):
raise new_exc_class(message) from exc
然后在业务方法中直接用：
try:
user = self._db.fetch_by_id(user_id)
except DatabaseError as e:
raise_as(e, UserNotFoundError, f"User {user_id} not found")
- 避免在
except块里构造新异常时漏掉from，尤其当message里拼接了变量，容易下意识只写raise UserNotFoundError(...) - 继承自
Exception的自定义异常类无需额外处理，Python 自动支持from - 如果原异常是
None（比如刚初始化未赋值），raise ... from None是安全的；但raise ... from some_var前务必确保some_var是Exception实例
调试时怎么确认异常链是否生效
运行时报错后，看终端输出里有没有两段 traceback 中间夹着 “The above exception was the direct cause of the following exception” 这句话。没有？那大概率没用对 from。
代码里验证更可靠：
try:
# 触发异常链的代码
except MyDomainError as e:
assert e.__cause__ is not None # 确认有因果链
assert isinstance(e.__cause__, OriginalErrorType)
-
e.__cause__对应from指定的异常；e.__context__是隐式捕获的前一个异常（比如没写from时的自动关联） - IDE 调试器里展开异常对象，手动检查
__cause__属性比靠肉眼读 traceback 更准 - 日志框架（如 structlog）若没配置好，可能只记录顶层异常，需显式传入
exc_info=True并确认其支持异常链序列化
异常链不是加了 from 就万事大吉——它让错误更可追溯，但也要求所有中间层都尊重这个契约。漏掉一次 from，整条链就断在那一环。
