使用自定义异常可明确表达业务错误，如“订单已过期”，通过继承RuntimeException并添加错误码，在支付场景中抛出OrderException，结合@ControllerAdvice统一返回结构化错误信息，提升系统可维护性和前后端协作效率。
在Java开发中，自定义异常不仅能提升代码的可读性和健壮性，还能与业务逻辑紧密结合，使程序在面对特定错误场景时具备更清晰的处理路径。通过将异常设计融入业务流程，开发者可以快速定位问题、统一错误响应，并增强系统的可维护性。
为什么要使用自定义异常
Java内置的异常类型（如IllegalArgumentException、RuntimeException）虽然覆盖常见错误，但难以表达具体业务含义。例如，“用户余额不足”或“订单已过期”这类问题，用通用异常无法直观体现错误本质。
自定义异常的优势包括：
- 明确表达业务错误类型
- 便于在日志或接口返回中统一处理
- 支持携带额外信息（如错误码、提示消息）
- 配合AOP或全局异常处理器实现集中响应
如何定义业务相关的自定义异常
通常继承RuntimeException（非检查异常）以避免强制try-catch，同时可根据需要添加构造方法和字段。
立即学习“Java免费学习笔记（深入）”；
示例：定义一个订单相关的异常public class OrderException extends RuntimeException {
private String errorCode;
public OrderException(String message, String errorCode) {
super(message);
this.errorCode = errorCode;
}
public String getErrorCode() {
return errorCode;
}
}
这样在抛出异常时，既能传递可读信息，也能保留系统识别用的错误码，便于前端或日志分析。
AGECMS商业会云管理电子名片是一款专为商务人士设计的全方位互动电子名片软件。它结合了现代商务交流的便捷性与高效性，通过数字化的方式，帮助用户快速分享和推广自己的专业形象。此系统集成了多项功能，包括个人信息展示、多媒体互动、客户管理以及社交网络连接等，是商务沟通和品牌推广的得力工具。 核心功能：个人及企业信息展示：用户可以自定义电子名片中的信息内容，包括姓名、职位、企业Logo、联系信息(电话、
在业务逻辑中合理抛出和捕获异常
将自定义异常嵌入服务层，能有效解耦校验逻辑与主流程。比如订单支付场景：
public void payOrder(Long orderId, BigDecimal amount) {
Order order = orderRepository.findById(orderId);
if (order == null) {
throw new OrderException("订单不存在", "ORDER_NOT_FOUND");
}
if (order.getStatus() == OrderStatus.PAID) {
throw new OrderException("订单已支付", "ORDER_ALREADY_PAID");
}
if (order.getAmount().compareTo(amount) != 0) {
throw new OrderException("支付金额不匹配", "AMOUNT_MISMATCH");
}
// 执行支付逻辑
}
调用方无需层层判断返回值，只需关注是否成功，失败则由统一异常处理器拦截并返回结构化结果。
结合全局异常处理器统一响应
在Spring Boot项目中，使用@ControllerAdvice捕获自定义异常，返回标准格式的错误信息。
@ControllerAdvice
public class GlobalExceptionHandler {
@ResponseBody
@ExceptionHandler(OrderException.class)
public ResponseEntity> handleOrderException(OrderException e) {
Map response = new HashMap<>();
response.put("success", false);
response.put("message", e.getMessage());
response.put("errorCode", e.getErrorCode());
return ResponseEntity.status(400).body(response);
}
}
这样前端收到的每次业务异常都具有一致的数据结构，降低处理复杂度。
基本上就这些。把异常当成业务语义的一部分来设计，而不是仅仅作为错误标志，能让系统更清晰、更易维护。关键是在团队内达成一致，规范异常的命名、分类和使用方式。
