自定义异常的核心目的是明确错误语义、支持分层处理、避免滥用泛化异常；需按业务建模，区分checked/unckecked类型，提供标准构造器及扩展字段，并在业务规则破坏时精准抛出。
在 Java 业务逻辑中，定义和抛出自定义异常的核心目的是让错误语义更清晰、便于分层捕获与处理，同时避免滥用 RuntimeException 或泛化异常（如 Exception）导致逻辑模糊。关键在于：**按业务场景建模异常类型，区分检查型（checked）与非检查型（unchecked），并在合适位置主动抛出、统一包装、避免裸 throw。
一、定义有意义的自定义异常类
不建议直接继承 Exception 或 RuntimeException 写一个空类。应体现业务含义，并支持常见扩展能力：
-
命名规范：以
Exception结尾，如InsufficientBalanceException、InvalidOrderStatusException -
继承选择：
- 需强制调用方处理（如资金扣减失败必须回滚并提示用户）→ 继承
Exception（检查型） - 属编程错误或不可恢复的运行时问题（如参数非法、状态机违例）→ 继承
RuntimeException（非检查型）
- 需强制调用方处理（如资金扣减失败必须回滚并提示用户）→ 继承
-
提供常用构造器：至少包含
(String message)和(String message, Throwable cause)，方便链式异常传递 -
可选增强：添加业务错误码（
errorCode）、HTTP 状态码字段、或实现Serializable（若需跨服务传输）
示例：
public class InsufficientBalanceException extends Exception {
private final String errorCode = "BALANCE_INSUFFICIENT";
private final int httpStatus = 400;
public InsufficientBalanceException(String message) {
super(message);
}
public InsufficientBalanceException(String message, Throwable cause) {
super(message, cause);
}
// 可提供 getter 供全局异常处理器读取
public String getErrorCode() { return errorCode; }
public int getHttpStatus() { return httpStatus; }
}
二、在业务方法中合理抛出
抛出时机不是“一有错就 throw”，而是聚焦**业务规则被破坏**的明确节点：
立即学习“Java免费学习笔记（深入）”；
- 校验失败后立即抛出，不继续执行后续逻辑（如订单创建时验证库存不足）
- 状态流转非法时抛出（如试图取消已发货的订单）
- 外部依赖返回明确业务错误（如支付网关返回“余额不足”）→ 封装为对应自定义异常，而非透传原始异常
- 避免在循环或高频路径中频繁抛异常（影响性能），必要时改用返回结果对象（如
Result<T>）
示例：
public Order createOrder(CreateOrderRequest request) {
Product product = productRepository.findById(request.getProductId());
if (product.getStock() < request.getQuantity()) {
throw new InsufficientStockException(
String.format("库存不足：商品 %s 仅剩 %d 件，需 %d 件",
product.getName(), product.getStock(), request.getQuantity())
);
}
// 后续创建逻辑...
}
三、配合全局异常处理器统一响应
Spring Boot 项目中，用 @ControllerAdvice + @ExceptionHandler 捕获自定义异常，屏蔽技术细节，返回前端友好的 JSON：
- 为每种自定义异常编写专属
@ExceptionHandler方法，设置 HTTP 状态码、错误码、提示文案 - 对非自定义异常（如
NullPointerException）做兜底处理，记录日志但不暴露堆栈 - 避免在 service 层 try-catch 自定义异常再转成 success/fail 返回——这会削弱异常的传播能力和语义性
示例：
@ControllerAdvice
public class GlobalExceptionHandler {
@ExceptionHandler(InsufficientStockException.class)
public ResponseEntity<ErrorResponse> handleInsufficientStock(InsufficientStockException e) {
ErrorResponse error = new ErrorResponse("STOCK_SHORTAGE", e.getMessage());
return ResponseEntity.status(HttpStatus.BAD_REQUEST).body(error);
}
}
四、注意几个易错点
实际开发中容易忽略的细节：
-
不要用异常控制正常流程：比如用
UserNotFoundException判断用户是否存在 → 应该先查再判断，而不是靠 catch 异常来分支 - 异常消息不要拼接敏感数据：如用户身份证号、银行卡号，防止日志泄露
-
嵌套异常要保留 cause：包装第三方 SDK 异常时，务必用
new BizException("xxx", originalException)，否则丢失根因 - 模块间异常尽量隔离：内部服务抛出的自定义异常，对外 API 层应转换为统一的对外异常体系，避免内部异常类型泄漏
不复杂但容易忽略：自定义异常的价值不在“能 throw”，而在于让业务意图可读、错误可分类、处理可预期。
