Java自定义异常命名须以Exception或Error结尾、采用大驼峰风格，体现具体业务场景；Checked异常继承Exception，Runtime异常继承RuntimeException；需置于模块对应的exception包下，避免与JDK/框架异常重名。

Java 自定义异常命名需以 Exception 或 Error 结尾，且采用大驼峰（PascalCase）风格；业务异常推荐用 xxxException，系统级错误用 xxxError；禁止使用 Exception 以外的后缀（如 Exc、Excep），也不得省略后缀。

异常类名必须体现业务含义

名称应清晰表达异常发生的具体场景或原因，避免泛化。例如：

• ✅ UserNotFoundException（用户未找到）
• ✅ InsufficientBalanceException（余额不足）
• ❌ MyException（无业务语义）
• ❌ UserEx（缩写不规范，缺后缀）

区分 Checked 和 Runtime 异常的命名倾向

阿里巴巴规范虽未强制要求从名称上区分，但实践中建议：

Java Maven Common

Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。

下载

• 继承 Exception 的（受检异常）：多用于外部可预期、需显式处理的业务异常，如 ThirdPartyServiceTimeoutException
• 继承 RuntimeException 的（非受检异常）：多用于程序逻辑错误或不可恢复问题，如 InvalidOrderStatusException
• 不推荐在类名中硬加 Checked 或 Runtime 字样（如 UserCheckedException），违背简洁性原则

包路径与模块归属要明确

异常类应放在对应业务模块的 exception 子包下，包名全小写，与模块名一致：

立即学习“Java免费学习笔记（深入）”；

• 订单模块： com.example.trade.exception.OrderException
• 用户模块： com.example.user.exception.UserDuplicateEmailException
• 避免放在通用包如 com.example.common.exception.BaseException 下直接定义具体异常

避免与 JDK 或主流框架异常重名或歧义

不要模仿或覆盖已有标准异常语义，例如：

• ❌ NullPointerException（JDK 已有，不得自定义同名）
• ❌ IllegalArgumentException（语义通用，应优先复用，而非另造 BizArgumentException）
• ✅ 需扩展时，应在语义上更具体：如 InvalidPromotionCodeException 比 IllegalArgumentException 更具业务上下文