Java自定义异常必须以Exception结尾并用大驼峰命名，错误码需枚举强绑定，消息要含动态上下文；如OrderNotFoundException、USER_NOT_FOUND、"订单号TX20261016001库存不足"。
Java 自定义异常的命名和错误编码规则不是风格选择，而是工程契约——它直接影响 IDE 识别、框架匹配、日志归类、团队协作和线上问题定位效率。
异常类名必须以 Exception 结尾，且用大驼峰命名
这是 JVM 生态的硬性约定，不是建议：
- 所有标准异常（NullPointerException、IllegalArgumentException）都严格遵循该后缀；
- Spring 的
@ExceptionHandler、IDE 的 Ctrl+Click 跳转、SonarQube 静态检查、Mockito 异常模拟等，全部依赖这个后缀做类型识别； - 写成
UserError或InvalidOrder，哪怕继承了RuntimeException，也会被当成普通类处理，导致捕获失败或编译警告。
正确示例：OrderNotFoundException、InsufficientBalanceException、ExpiredTokenException；
错误示例：UserException（语义模糊）、InvalidUserInput（缺后缀）、invld_input_exc（小写+下划线，违反 Java 类名规范）。
名称要直白体现业务语义，优先形容词+名词结构
命名目标不是“分类”，而是让调用方一眼看懂问题本质：
Java注释规范Skills
下载
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
立即学习“Java免费学习笔记（深入）”；
- 用户余额不足时，用 InsufficientBalanceException 比
PaymentException更精准； - 订单状态非法时，用 InvalidOrderStatusException 比
OrderException更明确； - 推荐结构：形容词 + 名词（如 MissingRequiredFieldException、ExpiredTokenException）；
- 避免动词开头（如
ValidateFailedException）、缩写（如InvldInputExc）、笼统命名（如MyException、BusinessRuntimeException）。
错误码需统一管理，推荐用枚举 + 异常类强绑定
错误码不能是散落在各处的字符串或数字，必须可读、可查、可维护：
- 格式采用 模块_动作/状态，如
USER_NOT_FOUND、ORDER_CREATE_FAILED、PAYMENT_TIMEOUT； - 避免纯数字（如
1001），不便于搜索、理解和协作； - 每个码对应唯一语义，上线后不可变更含义，废弃需显式标注；
- 通过枚举集中定义，含错误码、提示文案、HTTP 状态码等字段，并在自定义异常构造时传入，实现强绑定。
示例枚举：
public enum BizErrorCode {
USER_NOT_FOUND("USER_001", "用户不存在", HttpStatus.NOT_FOUND),
ORDER_INVALID_STATUS("ORDER_003", "订单状态非法", HttpStatus.BAD_REQUEST);
private final String code;
private final String message;
private final HttpStatus httpStatus;
// 构造与 getter 省略
}
异常类需携带上下文，消息内容要含关键变量
错误信息不是口号，而是排查依据：
- 抛出时不要只写
"操作非法"，而应包含动态上下文，如"用户ID=12345的状态不支持此操作"或"订单号TX20261016001库存不足"； - 若需传递业务 ID、时间戳、请求号等，可在异常类中添加字段（如
private String orderId;），并在构造器中接收； - 消息拼接应在抛出点完成，不在构造器里做远程调用或日志输出，保持轻量。
