Java可通过继承RuntimeException自定义业务异常（如BusinessException）并封装Asserts断言工具类，实现轻量、可读、高性能的业务校验机制，配合ErrorCode枚举与全局异常处理器形成完整错误管理体系。
Java中可以通过继承RuntimeException编写自定义运行时异常，再配合静态断言方法，快速构建轻量、可读性强的业务断言机制——无需引入第三方库，也不影响性能。
定义自定义业务异常类
创建一个继承RuntimeException的异常类，建议命名体现业务语义（如BusinessException），并提供多种构造方式，便于不同场景抛出：
- 支持仅传错误码（如
"USER_NOT_FOUND"） - 支持错误码 + 占位符参数（用于动态填充提示信息）
- 支持嵌套异常（便于排查链路问题）
示例代码：
public class BusinessException extends RuntimeException {
private final String code;
public BusinessException(String code) {
this(code, null, null);
}
public BusinessException(String code, Object... args) {
this(code, String.format(getMessageTemplate(code), args), null);
}
public BusinessException(String code, String message, Throwable cause) {
super(message, cause);
this.code = code;
}
// 可维护一个简单映射，或对接配置中心/资源文件
private static String getMessageTemplate(String code) {
return switch (code) {
case "USER_NOT_FOUND" -> "用户不存在（id=%s）";
case "INSUFFICIENT_BALANCE" -> "余额不足，当前：%s，需：%s";
default -> "业务异常[%s]";
};
}
public String getCode() {
return code;
}
}
封装静态断言工具类
新建Asserts类，提供类似Objects.requireNonNull风格的静态方法，但面向业务逻辑。关键点：
立即学习“Java免费学习笔记（深入）”；
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 方法名直白，如
notNull、isTrue、state（校验状态）、fail（无条件失败） - 每个方法接收错误码作为第一个参数，语义清晰，便于统一监控和国际化
- 避免过度重载，优先用
Object...承接动态参数
示例：
public class Asserts {
public static void notNull(Object obj, String code, Object... args) {
if (obj == null) {
throw new BusinessException(code, args);
}
}
public static void isTrue(boolean expression, String code, Object... args) {
if (!expression) {
throw new BusinessException(code, args);
}
}
public static void state(boolean expression, String code, Object... args) {
if (!expression) {
throw new BusinessException(code, args);
}
}
public static void fail(String code, Object... args) {
throw new BusinessException(code, args);
}
}
在业务代码中使用断言
将校验逻辑从“if-throw”模板中解放出来，让主干代码聚焦业务本身。注意三点：
- 错误码建议常量化（如
ErrorCode.USER_NOT_FOUND），避免散落字符串 - 参数顺序保持一致：错误码在前，动态值在后
- 不建议在循环内高频调用断言（除非必要），避免无谓开销
实际调用示例：
public User getUserById(Long id) {
Asserts.notNull(id, ErrorCode.PARAM_REQUIRED, "用户ID");
User user = userRepository.findById(id).orElse(null);
Asserts.notNull(user, ErrorCode.USER_NOT_FOUND, id);
Asserts.isTrue(user.isActive(), ErrorCode.USER_INACTIVE, user.getUsername());
return user;
}
配套建议：错误码与全局异常处理器
为提升可维护性，建议补充两个实践：
- 建立
ErrorCode枚举，集中管理所有业务错误码及其默认消息（可选） - 在Spring Boot项目中，搭配
@ControllerAdvice统一捕获BusinessException，返回标准响应结构（含code、message、timestamp等）
这样前端可直接根据code做精准交互，日志系统也能按码聚合分析异常趋势。
