工程中不能直接 raise Exception(‘xxx’)，因其导致错误类型无法区分、日志监控失效、单元测试难断言；应继承具体异常类并按领域语义命名，集中定义、分层设计（领域/基础设施/封装异常），构造函数需保留上下文，__str__ 避免敏感信息，对预期业务分支建议用 Result 类型而非异常。
为什么不能直接 raise Exception(‘xxx’)
工程中直接 raise Exception('xxx') 会导致调用方无法区分错误类型，所有异常都落在同一个基类上，没法做针对性处理。比如数据库连接失败、参数校验不通过、第三方服务超时，这三类问题本应触发不同恢复逻辑，但全被 Exception 吞掉后，只能统一打印日志或重启服务。
更实际的问题是：日志监控系统（如 Sentry、ELK）靠异常类名做聚合告警，如果全是 Exception，就失去分类统计意义；单元测试里也很难精准 assertRaises 某个业务场景。
- 必须继承
Exception或其子类（如ValueError、RuntimeError），不能裸用基类 - 异常类名要体现领域语义，例如
UserNotFoundError、PaymentValidationFailed，而不是MyException - 模块内异常建议集中定义在
exceptions.py，避免散落在各处导致重复或遗漏
如何设计分层的异常继承体系
大型项目需要按错误来源和处理责任分层，不是所有异常都要平级定义。常见三层结构：
-
领域异常（Domain Exceptions）：如
InsufficientBalanceError，表示业务规则被违反，调用方应检查输入或引导用户操作 -
基础设施异常（Infrastructure Exceptions）：如
DatabaseConnectionError、RedisTimeoutError，表示外部依赖不可用，通常需重试或降级 -
封装异常（Wrapper Exceptions）：如
UserServiceError，用于对外暴露统一入口异常，屏蔽内部实现细节
注意：不要为了分层而深继承。例如 class DatabaseConnectionError(InfraError) → class InfraError(ServiceError) → class ServiceError(Exception) 这种四层链容易让开发者困惑“到底该 catch 哪一层”。一般两层足够：BaseAppError + 具体业务/ infra 异常。
立即学习“Python免费学习笔记（深入）”；
