定义继承Exception的CustomCheckedException类，包含消息、异常链和错误码；2. 在业务逻辑如转账时余额不足抛出该异常，强制调用方处理，提升代码规范性与可维护性。
在Java开发中，使用自定义检查异常（CustomCheckedException）对业务异常进行建模，有助于提升代码的可读性、可维护性和错误处理的规范性。Checked异常强制调用方显式处理，适合用于业务流程中可预期但需要干预的错误场景，比如参数校验失败、账户余额不足、权限不足等。
1. 定义CustomCheckedException类
创建一个继承自Exception的自定义异常类，而不是RuntimeException，以确保其为检查异常，编译器会强制调用者处理。
建议包含以下元素：
- 无参构造函数
- 接收消息字符串的构造函数
- 接收Throwable的构造函数（支持异常链）
- 可选：添加业务错误码字段
示例代码：
立即学习“Java免费学习笔记（深入）”；
public class CustomCheckedException extends Exception {
private String errorCode;
public CustomCheckedException() {
super();
}
public CustomCheckedException(String message) {
super(message);
}
public CustomCheckedException(String message, Throwable cause) {
super(message, cause);
}
public CustomCheckedException(String errorCode, String message) {
super(message);
this.errorCode = errorCode;
}
public CustomCheckedException(String errorCode, String message, Throwable cause) {
super(message, cause);
this.errorCode = errorCode;
}
public String getErrorCode() {
return errorCode;
}
}
2. 在业务逻辑中抛出CustomCheckedException
在服务层或业务方法中，当检测到特定业务规则被违反时，主动抛出该异常。
例如用户转账操作中余额不足：
public void transferMoney(String fromAccount, String toAccount, BigDecimal amount)
throws CustomCheckedException {
if (amount.compareTo(BigDecimal.ZERO) <= 0) {
throw new CustomCheckedException("INVALID_AMOUNT", "转账金额必须大于零");
}
BigDecimal balance = accountRepository.getBalance(fromAccount);
if (balance.compareTo(amount) < 0) {
throw new CustomCheckedException("INSUFFICIENT_BALANCE", "账户余额不足");
}
// 执行转账逻辑
}
3. 调用方显式处理异常
由于是checked exception，调用者必须使用try-catch或继续向上抛出。
典型处理方式：
try {
accountService.transferMoney("A", "B", new BigDecimal("100.00"));
} catch (CustomCheckedException e) {
System.err.println("业务异常：" + e.getMessage());
if (e.getErrorCode() != null) {
System.err.println("错误码：" + e.getErrorCode());
}
// 可记录日志、返回前端提示、触发补偿流程等
}
4. 结合错误码与国际化提升用户体验
实际项目中，可将errorCode映射为资源文件中的提示信息，支持多语言。
例如配置properties文件：
INSUFFICIENT_BALANCE=您的账户余额不足，请充值后再试。 INVALID_AMOUNT=转账金额不合法，请输入正确的数值。
在捕获异常后根据errorCode查找对应提示返回给前端。
基本上就这些。通过合理设计CustomCheckedException并结合业务语义，可以让异常处理更清晰、系统更健壮。关键是明确哪些异常属于“可恢复的业务场景”，才适合作为checked exception建模。不要滥用，避免代码被过多try-catch污染。
