Java异常命名规范解析

Java自定义异常类必须以Exception结尾，采用PascalCase命名，用动宾结构准确描述问题场景，如InvalidOrderException；大型项目可选加BusinessException等语义前缀。

Java中自定义异常类的命名，核心就一条：必须以 Exception 结尾。这不是可选项，而是行业共识和可读性刚需——一眼就能识别这是异常类型，不混淆、不猜测。

必须以 Exception 结尾

所有自定义异常类名都应以 Exception 作为后缀，这是 Java 标准库（如 IOException、IllegalArgumentException）长期确立的约定。

• ✅ 正确示例：InvalidOrderException、PaymentTimeoutException、ConfigLoadException
• ❌ 错误示例：OrderError、BadPayment、ConfigFailure（语义模糊，且无法体现异常本质）

用准确、具体的动宾结构描述问题场景

名称不是越短越好，而是要让人看到名字就大致明白“什么情况下抛出”“问题出在哪”。优先使用动词+名词或形容词+名词组合，避免宽泛词如 GeneralException、UserException。

• 推荐：InsufficientStockException（库存不足）、ExpiredTokenException（令牌过期）、UnsupportedCurrencyException（币种不支持）
• 慎用：UserException（太笼统）、SystemException（与 JDK 的 java.lang.SystemException 易混淆）

严格遵守 PascalCase（大驼峰）命名法

类名每个单词首字母大写，不加下划线，不全小写，不混用大小写风格。

• ✅ 正确：DataValidationException、ExternalServiceUnavailableException
• ❌ 错误：data_validation_exception（下划线，像常量）、datavalidationexception（全小写）、Data_Validation_Exception（含下划线）

可选但实用：通过前缀区分异常性质

大型项目中，为便于归类和治理，可在 Exception 前添加语义前缀，但非强制：

• BusinessException：业务规则校验失败（如余额不足、重复下单）
• SystemException：底层资源异常（如数据库连接断开、Redis超时）
• ApiException：面向外部 API 的统一错误包装（常用于网关或 REST 接口层）

注意：不建议强行加 Checked 或 Runtime 前缀，因为是否检查由继承关系决定（extends Exception 是 checked；extends RuntimeException 是 unchecked），而非名字。