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（大驼峰）命名法
类名每个单词首字母大写，不加下划线，不全小写，不混用大小写风格。
立即学习“Java免费学习笔记（深入）”；
- ✅ 正确：
DataValidationException、ExternalServiceUnavailableException - ❌ 错误：
data_validation_exception（下划线，像常量）、datavalidationexception（全小写）、Data_Validation_Exception（含下划线）
可选但实用：通过前缀区分异常性质
大型项目中，为便于归类和治理，可在 Exception 前添加语义前缀，但非强制：
-
BusinessException：业务规则校验失败（如余额不足、重复下单） -
SystemException：底层资源异常（如数据库连接断开、Redis超时） -
ApiException：面向外部 API 的统一错误包装（常用于网关或 REST 接口层）
注意：不建议强行加 Checked 或 Runtime 前缀，因为是否检查由继承关系决定（extends Exception 是 checked；extends RuntimeException 是 unchecked），而非名字。
