Java自定义异常必须以Exception结尾并用大驼峰命名，因JDK、IDE、框架和工具均依赖该后缀识别异常类型；命名需体现具体业务场景，如InsufficientBalanceException；多数业务异常应继承RuntimeException，不加Runtime前缀；包路径要体现领域层级，并封装errorCode字段。
Java自定义异常必须以 Exception 结尾，且用大驼峰命名（PascalCase），否则就不是合格的异常类——这是JVM生态里最基础、最不容妥协的约定。
为什么必须以 Exception 结尾？
这不是风格偏好，而是类型识别契约。JDK标准库所有异常（NullPointerException、IOException、IllegalArgumentException）都严格遵循该后缀；IDE、日志框架、Spring异常处理器、甚至静态分析工具（如SpotBugs）都依赖这个命名特征做自动识别和分类。
- 不加
Exception：IDE不会高亮为异常类型，catch块无法匹配，throws声明报错 - 写成
InvalidUserError或UserException：前者被当成Error子类（严重不可恢复），后者语义模糊，团队协作时没人敢确定它是业务异常还是技术异常 - 小写或下划线（如
invalid_user_exception）：违反Java类名规范，编译器虽不拦，但会被SonarQube等工具标为“命名违规”
怎么起一个真正有用的异常名？
名字要像错误日志一样能直接回答“谁在什么场景下因何失败”。避免泛化词（如 BusinessException、SystemException），优先绑定具体业务动词+名词。
- ✅ 推荐：
InsufficientBalanceException、OrderAlreadyPaidException、ProductOutOfStockException - ❌ 避免：
BalanceException（缺动词，不知是“不足”还是“超限”）、PayException（太宽泛，支付失败？支付超时？支付签名错？） - ⚠️ 注意：若涉及分层（如DAO/Service），可在包路径中体现，类名本身不强行加
Dao、Service前缀——com.example.order.exception.OrderNotFoundException比OrderServiceException更清晰
继承 RuntimeException 还是 Exception？命名要不要体现这点？
绝大多数业务异常应继承 RuntimeException（即“非检查异常”），让调用方按需捕获，而非强制 try-catch 或 throws。命名上不建议加 Runtime 或 Checked 前缀（如 RuntimeValidationException）——这会增加认知负担，且无实际约束力。
- ✅ 正确做法：统一用
XXXException命名，通过继承关系区分语义，例如：public class PaymentFailedException extends RuntimeException { ... } - ❌ 不推荐：
CheckedPaymentException—— 既没解决检查逻辑，又让名字变长，还可能误导人以为它必须被声明 - ? 关键判断点：如果这个异常代表“业务规则被违反”（如余额不足、库存不够），就用
RuntimeException子类；如果代表“外部系统暂时不可用”（如数据库连不上、HTTP调用超时），才考虑继承Exception并强制上层处理
容易被忽略的细节：包结构与错误码耦合
光有好名字不够，异常类必须放在合理包路径下，并配合错误码设计，否则名字再准也白搭。
- 包路径应反映领域层级：
com.example.payment.exception而非com.example.common.exception——后者会让所有模块异常混在一起，失去业务上下文 - 异常类内部最好封装
errorCode字段（如private final int errorCode = 4001;），前端或监控系统靠它做精准响应，而不是解析getMessage()字符串 - 别把“命名规范”当孤立任务：一个
OrderNotFoundException如果抛出时没带订单ID、没记录traceId、没关联错误码，那名字再标准也没法快速定位问题
