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