避免过度自定义异常，保持代码简洁清晰

本文深入探讨了如何理性对待自定义异常——核心不是一味减少数量，而是精准判断“何时必须自定义”：仅当需承载独特业务语义、支持差异化错误处理、携带结构化上下文或满足跨模块协同需求时才新建异常类；其余场景应复用标准异常或采用“通用异常类+枚举驱动”的轻量组合方案，并通过代码评审、静态检查和定期治理等机制将规范落到实处，最终倡导一种更成熟、更克制的异常设计哲学：把“不定义”本身当作一项需要勇气与洞察力的主动决策。

避免项目中异常类泛滥，关键不是“少定义”，而是“定义得对”——只在真正需要差异化处理、携带特定语义或需跨模块传递上下文时才自定义异常；其余情况直接复用标准异常或简单包装。

明确自定义异常的必要条件

以下情况才建议新建异常类：

• 业务场景有明确且不可被其他异常覆盖的语义（如 InsufficientBalanceException 比 IllegalArgumentException 更能表达资金不足的业务含义）
• 需要在 catch 块中被精确识别并执行特定恢复逻辑（例如重试、降级、告警分类）
• 必须携带额外结构化字段（如错误码、traceId、原始请求参数），且这些信息无法通过异常消息或嵌套异常合理传递
• 被多个子模块依赖，且各模块对同一错误的响应策略不同（如支付模块抛出，风控模块需拦截，日志模块需脱敏记录）

优先用组合替代继承，控制类数量

不必为每个业务错误码都建一个类。可设计通用基类 + 枚举驱动：

• 定义一个 BusinessException，包含 errorCode、errorMessage、details 字段
• 用枚举统一管理所有业务错误（如 ErrorCode.INSUFFICIENT_BALANCE），含默认提示、HTTP 状态码、是否可重试等元信息
• 抛出时只需 throw new BusinessException(ErrorCode.INSUFFICIENT_BALANCE, "余额不足")
• 捕获方可通过 exception.getErrorCode() 分支处理，无需 import 大量异常类

建立异常治理规范并落地检查

靠人自觉容易回退，需机制保障：

• 在代码评审清单中加入“新增异常类是否满足必要条件”条目，要求 PR 描述清楚使用场景和不可替代性
• 用 SonarQube 或自定义 Checkstyle 规则限制异常类命名空间（如只允许在 exception 包下，且禁止出现 XXXException2、TempException 等模糊命名）
• 定期扫描项目中所有 *Exception.java 文件，统计继承链深度、空实现类、仅用于 throw new XXXException() 无任何额外字段/方法的类，标记待清理

把“不定义”变成一种显式决策

当遇到新错误场景，先问自己三个问题：

• 这个错误能否用 IllegalArgumentException、IllegalStateException、RuntimeException 精准表达？
• 下游调用方是否真的需要根据这个异常类型做不同处理？还是只打印日志或返回固定错误码？
• 如果今天不定义它，半年后加监控、写单元测试、做灰度分流时会不会卡住？

多数时候答案是否定的。留白比堆砌更需要判断力。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~