17370845950

Python异常机制的核心是清晰表达错误语义与责任归属；自定义异常应命名明确（名词+Error）、继承合理（按语义选基类）、构造简洁（关键上下文入msg）、捕获精准（分层处理）。

Python 的异常机制不是用来控制流程的，而是为了清晰表达“出错时发生了什么”以及“谁该负责处理”。自定义异常的核心目标是让错误语义明确、层级合理、易于捕获和调试，而不是堆砌类名或过度封装。

命名清晰：用名词表达错误本质

异常类名应是名词性短语，以 Error 或 Exception 结尾（推荐统一用 Error，与标准库主流风格一致），直接说明问题类型，避免动词或模糊表述。

• ✅ 推荐：InvalidConfigError、NetworkTimeoutError、PermissionDeniedError
• ❌ 避免：HandleConfigFailed（动词）、MyAppError（太泛）、BadValue（缺后缀且语义弱）

继承合理：按语义分层，不盲目套用标准异常

自定义异常应继承自语义最贴近的内置异常，通常首选 Exception；若属于 I/O 类错误可考虑 OSError，逻辑错误可用 ValueError 或 TypeError，但前提是语义真正匹配。不要为“看起来更专业”而强行继承冷门基类。

• 配置解析失败 → 继承 ValueError（值不符合预期）或新建 ConfigParseError（继承 Exception）更自然
• 远程服务不可达 → 可继承 OSError（底层网络属系统资源范畴），而非硬塞进 RuntimeError
• 所有业务异常建议统一继承一个顶层基类（如 AppError），便于全局捕获：except AppError:

构造简洁：只保留必要信息，避免冗余字段

异常实例应通过 __init__ 接收关键上下文（如出错字段名、无效值、HTTP 状态码），并透传给父类初始化。不建议添加 getter 方法或复杂属性——异常对象应轻量，信息通过 str() 或 args 即可获取。

• 好做法：raise InvalidConfigError("timeout", value=30, unit="seconds")，在 __init__ 中拼接清晰提示
• 不推荐：定义 .field_name、.suggestion 等额外属性，除非调试强依赖且无法通过消息体现
• 提示消息中包含具体值和位置（如 "Field 'retry_limit' must be > 0, got -2"），比抽象描述更有助于定位

捕获精准：按需分层处理，避免宽泛 except Exception

业务代码应根据恢复能力决定捕获粒度：能重试的捕获具体异常（如 NetworkTimeoutError），需降级的捕获基类（如 AppError），仅日志兜底才用 except Exception。同时，自定义异常要预留扩展空间——例如带 status_code 属性的 API 错误，方便上层统一转 HTTP 响应。

• API 视图中：except ValidationError as e: return json_error(400, str(e))
• 任务重试逻辑：except (NetworkTimeoutError, ConnectionResetError): retry()
• 主程序入口：except AppError as e: logger.error(...); sys.exit(1)

异常不是错误日志的替代品，也不是流程分支的伪装。设计得当的自定义异常，能让调用方一眼看懂“出了什么错、是否可恢复、该不该继续”，这才是它存在的全部意义。