Python 如何设计“可恢复”的异常？

Python中无原生可恢复异常，但可通过自定义RetryableError类标记可重试错误，配合except块修复状态、重试机制（如装饰器）、上下文管理器资源清理，实现逻辑上的可恢复行为。

Python 中没有原生的“可恢复异常”类型，但可以通过设计自定义异常类、配合 try...except 与状态管理，实现逻辑上的“可恢复”行为——即异常发生后，程序能修正问题并重试，而非直接终止或跳过。

用自定义异常标记“可重试错误”

定义一个继承自 Exception 的基类（如 RetryableError），让调用方明确知道该异常允许且预期被恢复。它本身不带恢复能力，但起语义和分类作用。

• 避免与 ValueError、KeyError 等通用异常混用，便于统一拦截
• 可附加字段，如 retry_after=2、recoverable=True，供上层决策
• 示例：

  class NetworkTimeoutError(RetryableError): pass

在异常处理中主动恢复状态

“可恢复”的核心不在异常本身，而在 except 块里做了什么。常见做法包括重连、刷新凭证、清理缓存、切换备用资源等。

• 捕获自定义可重试异常后，执行修复动作（如 session.refresh_token()）
• 修复完成后，可选择 contin

  

  ue 重试循环，或显式调用原逻辑
• 注意避免无限重试：应设最大重试次数或退避策略（如指数退避）

封装成带重试逻辑的函数或装饰器

把“抛出 → 捕获 → 恢复 → 重试”流程抽象出来，提升复用性。例如：

• 写一个 @retry_on(RetryableError, max_attempts=3) 装饰器，内部自动捕获、调用恢复钩子、延迟重试
• 恢复钩子可以是传入的函数（如 on_retry=lambda: db.reconnect()）
• 比裸写 try/except/while 更清晰，也更容易测试和配置

配合上下文管理器控制资源生命周期

若异常涉及资源（如文件、连接、锁），需确保恢复前资源已安全释放或重置。

• 使用 with 确保 __exit__ 正常执行，避免残留状态干扰恢复
• 自定义上下文管理器可在 __exit__ 中判断是否为可恢复异常，并触发清理+预热操作
• 例如：网络请求上下文在捕获 NetworkTimeoutError 后，自动关闭旧连接并新建一个

# python  # 封装  # while  # session 

相关栏目： <？ｍｕｍａ $count = M('archives')->where(['typeid'=>$field['id']])->count(); ?> 【 AI推广<？ｍｕｍａ echo $count; ?> 】 <？ｍｕｍａ $count = M('archives')->where(['typeid'=>$field['id']])->count(); ?> 【 SEO优化<？ｍｕｍａ echo $count; ?> 】 <？ｍｕｍａ $count = M('archives')->where(['typeid'=>$field['id']])->count(); ?> 【 技术百科<？ｍｕｍａ echo $count; ?> 】 <？ｍｕｍａ $count = M('archives')->where(['typeid'=>$field['id']])->count(); ?> 【 谷歌推广<？ｍｕｍａ echo $count; ?> 】 <？ｍｕｍａ $count = M('archives')->where(['typeid'=>$field['id']])->count(); ?> 【 百度推广<？ｍｕｍａ echo $count; ?> 】 <？ｍｕｍａ $count = M('archives')->where(['typeid'=>$field['id']])->count(); ?> 【 网络营销<？ｍｕｍａ echo $count; ?> 】 <？ｍｕｍａ $count = M('archives')->where(['typeid'=>$field['id']])->count(); ?> 【 案例网站<？ｍｕｍａ echo $count; ?> 】 <？ｍｕｍａ $count = M('archives')->where(['typeid'=>$field['id']])->count(); ?> 【 精选文章<？ｍｕｍａ echo $count; ?> 】