自定义异常需继承内置异常类并重写__init__以添加属性，用raise直接抛出；捕获后重抛应使用裸raise或raise...from...保留traceback；异常消息禁止包含敏感信息。
用 raise 语句抛出自定义异常最直接
Python 中没有“触发异常”的中间步骤，raise 就是唯一且立即生效的操作。它不依赖装饰器、信号或事件循环，执行到那一行就中断当前流程，向上冒泡。
常见错误是试图用 Exception() 实例代替类名，比如写成 raise Exception("msg") 虽然能运行，但丢失了异常类型信息，后续 except 捕获时无法区分业务逻辑错误和通用错误。
- 正确写法：定义一个继承自
Exception（或其子类）的类，然后raise它的实例 - 推荐继承
ValueError、RuntimeError等内置类型，语义更清晰；不要全用Exception - 构造函数参数会传给父类
__init__，通常第一个字符串参数成为str(exc)的输出
class InvalidConfigError(ValueError):
pass
<p>if not config.get("host"):
raise InvalidConfigError("missing 'host' in config")</p>
自定义异常类里加属性要重写 __init__
默认的 Exception 只把参数存进 args，想带状态码、原始数据或上下文字段，必须手动赋值并调用父类初始化。
容易踩的坑是只写 self.code = code 却忘了调用 super().__init__(message)，导致 str(exc) 返回空或报错。
- 所有你想在
except块里直接访问的字段，都得在__init__里显式设置 - 避免覆盖
args或__str__，除非你清楚影响日志和调试输出 - 如果需要序列化（如记录到 JSON），建议加一个
to_dict()方法，而不是依赖__dict__
class ApiError(RuntimeError):
def __init__(self, message, status_code=500, response_body=None):
super().__init__(message)
self.status_code = status_code
self.response_body = response_body
<h1>使用</h1><p>raise ApiError("timeout", status_code=408, response_body={"error": "request timeout"})</p><div class="aritcle_card flexRow artxards">
<div class="artcardd flexRow">
<a class="aritcle_card_img" rel="nofollow" href="/xiazai/skill8054" title="python-parallelization"><img
src="https://img.php.cn/upload/skill/000/000/081/179181013081932.jpg" alt="python-parallelization" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
<div class="aritcle_card_info flexColumn">
<a rel="nofollow" href="/xiazai/skill8054" title="python-parallelization" class="overflowclass">python-parallelization</a>
<p class="overflowclass">将顺序 Python 代码转换为并行/并发实现，用于在需要并行化 Python 代码、提升性能时使用。</p>
</div>
<a rel="nofollow" href="/xiazai/skill8054" title="python-parallelization" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
</a>
</div>
</div>
在 except 中重新抛出要小心丢失 traceback
捕获后再抛出（比如做日志或转换异常类型），用裸 raise 才保留原始 traceback；如果写成 raise NewError(...)，就会丢掉原始位置信息，排查时只能看到 raise 那一行。
另一个常见问题是误用 sys.exc_info() 手动构造异常，既冗余又易错——Python 3.7+ 已支持 raise NewError(...) from exc 显式链式异常。
- 原样重抛：直接写
raise（不带参数） - 转为新类型并保留因果：用
raise NewError(...) from exc - 完全替换（放弃原始 traceback）：仅当明确知道后果时才用
raise NewError(...)
try:
risky_operation()
except ValueError as e:
logger.warning("fallback to default", exc_info=True)
raise RuntimeError("operation failed") from e
别在异常消息里拼接敏感数据
异常对象可能被记录到日志、监控系统甚至返回给前端（尤其开发环境），str(exc) 里的内容默认可读。如果消息里含密码、token、用户邮箱，等于主动泄露。
更隐蔽的问题是：有些 ORM 或 HTTP 客户端会在异常消息中自动包含原始 SQL 或请求体，而开发者没意识到这会被暴露。
- 异常消息只放必要提示，如 "database connection refused"，不要写 "failed to connect to postgres://user:pwd@host/db"
- 敏感字段应作为异常实例属性单独存放，不在
args或__str__中体现 - 上线前检查所有
raise语句，特别是封装过的工具函数和 SDK 错误包装逻辑
自定义异常真正难的不是写法，而是设计时想清楚：这个错误该由谁处理？要不要带额外字段？traceback 是帮助定位还是制造干扰？这些决定了它在真实系统里能不能被有效利用。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
