raise ... from None 仅抑制异常链显示，不转换异常类型；正确做法是捕获原异常后手动构造并抛出新异常，显式传递关键信息，避免依赖自动迁移或丢失上下文。
为什么 raise from None 不能直接转换异常类型
很多人以为写 raise MyBusinessError() from None 就能“把原始异常换成自定义异常”，其实不是。Python 的 from None 只是抑制异常链显示，并不改变当前异常对象的类型或内容——它只是让 traceback 不显示 During handling of the above exception, another exception occurred: 那段提示，底层抛出的仍是 MyBusinessError，原始异常被丢弃了。
真正需要的是：捕获原异常 → 构造新异常 → 显式抛出（不带链），且通常还要保留原始异常的关键信息（比如错误码、消息片段）。
正确做法：用 raise MyBusinessError(...) from None 手动构造新异常
核心是别依赖原始异常的属性自动迁移，而是主动提取、重组、再抛出。常见场景如数据库操作失败转为 OrderCreationFailed：
try:
order = create_order_in_db(data)
except DatabaseConnectionError as e:
# 提取关键上下文，不依赖 e.args 自动传递
raise OrderCreationFailed(f"DB offline: {e.message or str(e)}") from None
except IntegrityError as e:
raise OrderCreationFailed(f"Duplicated order: {e.detail}") from None
-
from None放在最后，确保 traceback 干净，只显示你定义的异常 - 不要写
raise OrderCreationFailed() from e—— 这会保留异常链，不符合“转换”意图 - 避免直接用
str(e)拼接却不加前缀，否则日志里分不清是哪层抛的
容易踩的坑：from None 不等于“吞掉异常上下文”
有些同学加了 from None 就以为可以省略原始异常信息，结果业务排查时发现只有 OrderCreationFailed，连 HTTP 状态码或 SQL 错误号都丢了。
- 自定义异常类最好预留字段存原始错误码，比如
OrderCreationFailed(code=e.code, message=...) - 如果原始异常有结构化属性（如
e.status_code、e.error_id），务必显式传入新异常构造器 -
from None后无法通过__cause__或__context__访问原异常 —— 这是设计使然，不是 bug
进阶：统一异常转换工具函数（避免重复写 from None）
当多个地方都要做类似转换时，封装一个函数比每处手写更可靠：
def reraise_as(target_exc_class, message=None, **kwargs):
if message is None:
message = "Unknown error"
exc = target_exc_class(message, **kwargs)
raise exc from None
使用
try:
do_something()
except ValueError as e:
reraise_as(InvalidInputError, f"Bad format: {e}", field="email")
注意这个函数内部仍要显式构造异常对象，不能接收原始异常实例并“改类型”——Python 不允许运行时篡改异常类型。
最常被忽略的一点：自定义异常的 __init__ 是否兼容位置参数和关键字参数？如果父类是 Exception，默认只接受 *args，但上面例子中传了 field=...，就得自己实现参数转发逻辑，否则会报 TypeError: __init__() got an unexpected keyword argument。
