Java非受检异常 VS 受检异常

在业务自定义异常的设计中，优先选择非受检异常（RuntimeException子类）通常是更优方案，但需根据具体场景权衡。以下是深度分析和决策指南：

---

一、核心对比：非受检异常 vs 受检异常

维度	非受检异常（RuntimeException）	受检异常（Exception）
强制处理	调用方不强制捕获或声明	编译器强制处理（try-catch/throws）
适用场景	业务逻辑错误、不可恢复错误	可恢复错误、需显式处理的场景
代码侵入性	低（不污染方法签名）	高（方法需声明throws，调用链需处理）
设计哲学	“Fail-Fast” 快速暴露问题	“防御式编程” 确保错误被处理
典型案例	IllegalArgumentException	IOException

---

二、优先选择非受检异常的场景（推荐主流方案）

1. 不可恢复的业务错误

• 如订单状态冲突、ID不存在等业务规则违反
• 示例：

  // 非受检业务异常：调用方无法通过代码修复此错误
  class OrderStateException extends RuntimeException {
      public OrderStateException(String message) {
          super("订单状态冲突: " + message);
      }
  }
  
  // 使用处 - 无需声明throws
  public void cancelOrder(Order order) {
      if (order.isPaid()) {
          throw new OrderStateException("已支付订单不可取消");
      }
      // 取消逻辑...
  }

2. 参数校验失败

• 调用方传递非法参数（如null值、范围超限）
• 示例：

  // 继承RuntimeException
  class InvalidInputException extends RuntimeException {}
  
  public void updatePrice(double price) {
      if (price < 0) {
          throw new InvalidInputException("价格不可为负数");
      }
      // 更新逻辑...
  }

3. 分层架构中的跨层异常

• 在Service层抛出，由Controller层统一捕获处理（避免污染中间层）
• 优势：保持Service接口纯净，无throws声明

  // Service层
  @Service
  public class UserService {
      public User getUserById(Long id) {
          return userRepo.findById(id)
                 .orElseThrow(() -> new UserNotFoundException(id)); // 非受检
      }
  }
  
  // Controller层统一处理
  @RestControllerAdvice
  public class GlobalExceptionHandler {
      @ExceptionHandler(UserNotFoundException.class)
      public ResponseEntity<Error> handleUserNotFound(UserNotFoundException ex) {
          return ResponseEntity.status(404).body(new Error(ex.getMessage()));
      }
  }

4. 与框架集成

• Spring、JPA等主流框架默认使用非受检异常
• 如Spring的DataAccessException（数据库访问错误）

---

三、选择受检异常的场景（谨慎使用）

1. 明确要求调用方处理的业务错误

• 需调用方主动干预的场景（如支付失败需重试）
• 示例：

  // 受检异常：要求调用方必须处理支付失败
  class PaymentFailedException extends Exception {
      public PaymentFailedException(String message) {
          super("支付失败: " + message);
      }
  }
  
  // 方法明确声明throws
  public void processPayment() throws PaymentFailedException {
      if (paymentGateway.isDown()) {
          throw new PaymentFailedException("支付网关不可用");
      }
      // 支付逻辑...
  }
  
  // 调用方必须处理
  try {
      paymentService.processPayment();
  } catch (PaymentFailedException ex) {
      retryPayment(); // 显式重试逻辑
  }

2. 需要编译期保障安全性的场景

• 如金融系统核心操作，要求绝对不能忽略错误

---

四、最佳实践与避坑指南

1. 统一异常处理机制

   • 使用 @ControllerAdvice（Spring）或全局异常处理器捕获非受检异常
   • 避免在每个方法中重复 try-catch

2. 保持异常信息丰富

   • 包含业务关键数据（如订单ID、用户账号）

   // 反例：缺乏上下文
   throw new OrderException("操作失败");
   
   // 正例：包含业务标识
   throw new OrderException("订单["+orderId+"]库存不足");

3. 避免过度自定义

   • 优先使用标准异常：

     // 标准异常足够表达时无需自定义
     if (value < 0) throw new IllegalArgumentException("值不能为负");

4. 受检异常改造技巧

   • 若需减少侵入性，可包装为非受检异常：

     try {
         legacyCodeThrowsCheckedException();
     } catch (CheckedException e) {
         throw new BusinessRuntimeException(e); // 转换为非受检
     }

5. 团队统一规范

   • 制定团队异常公约（如：”业务异常一律继承RuntimeException”）

---

五、行业趋势

• 现代框架选择：Spring、Hibernate 等主流框架全面采用非受检异常
• 语言设计趋势：Kotlin/Scala 取消受检异常，Java 新特性（如 CompletableFuture）减少受检异常使用
• 微服务实践：在服务边界统一处理异常（如返回HTTP 4xx/5xx），内部使用非受检异常保持代码简洁

---

结论

优先选择非受检异常（RuntimeException子类） 作为业务自定义异常，尤其在：

• 分层架构中（如Service层异常由Controller统一处理）
• 不可恢复的业务错误（如状态冲突）
• 参数校验失败等逻辑错误场景

仅在要求调用方必须显式处理的特定业务场景下使用受检异常（如支付失败需重试）。现代Java开发中，非受检异常因其低侵入性和与框架的良好集成，已成为业务异常设计的事实标准。