Java 异常处理最佳实践：已选中、未选中与自定义异常全解

在构建高可用、高并发的 Java 后端系统时，例外处理是至关重要的一环。选择合适的异常类型并妥善处理，能够极大地提升系统的健壮性和可维护性。本文将深入探讨 Java 中的已选中异常（Checked Exception）、未选中异常（Unchecked Exception）以及自定义异常，并通过实际案例分享最佳实践和避坑经验。

1. 问题场景重现：一次糟糕的支付接口异常处理

假设我们正在开发一个电商平台的支付接口，需要调用第三方支付服务。由于网络波动、支付服务商故障等原因，调用第三方接口时可能会抛出各种异常。如果对这些异常处理不当，可能会导致订单支付失败、数据不一致等严重问题。

例如，我们最初的代码可能是这样的：

public void pay(Order order) {
 try {
 // 调用第三方支付接口
 thirdPartyPaymentService.pay(order.getAmount());
 // 更新订单状态为已支付
 order.setStatus(OrderStatus.PAID);
 } catch (Exception e) {
 // 记录日志
 logger.error("支付失败：", e);
 // 简单地返回错误信息
 throw new RuntimeException("支付失败");
 }
}

这段代码存在几个问题：

• 过度捕获：catch (Exception e) 捕获了所有异常，包括运行时异常和已检查异常，使得我们无法针对不同类型的异常进行精细化处理。
• 异常信息丢失：throw new RuntimeException("支付失败") 抛出了一个新的运行时异常，原始异常的信息丢失，不利于问题排查。
• 缺乏重试机制：对于偶发的网络波动等问题，没有重试机制，可能会导致不必要的支付失败。

2. 底层原理深度剖析：已选中异常 vs. 未选中异常

Java 中的异常分为两大类：

• 已选中异常（Checked Exception）：必须在代码中显式地捕获或声明抛出。编译器会强制检查已选中异常的处理情况。常见的已选中异常包括 IOException、SQLException 等。
• 未选中异常（Unchecked Exception）：不需要在代码中显式地捕获或声明抛出。编译器不会强制检查未选中异常的处理情况。常见的未选中异常包括 NullPointerException、IllegalArgumentException、RuntimeException 等。

已选中异常的设计目的是提醒开发者处理可能发生的异常情况，提高程序的健壮性。但是，过度使用已选中异常会增加代码的复杂度，降低开发效率。因此，在选择异常类型时需要权衡利弊。

3. 代码/配置解决方案：优化支付接口的异常处理

为了解决上述问题，我们可以采取以下措施：

1. 精确捕获异常：针对不同的异常类型，进行不同的处理。例如，对于网络连接异常，可以进行重试；对于参数错误异常，可以直接返回错误信息。
2. 保留原始异常信息：在抛出新的异常时，将原始异常作为参数传入，保留原始异常的信息。
3. 引入重试机制：对于偶发的异常，引入重试机制，提高支付成功率。
4. 自定义异常：针对特定的业务场景，可以自定义异常类型，更好地表达业务含义。

下面是优化后的代码示例：

import org.springframework.retry.annotation.Backoff;
import org.springframework.retry.annotation.Retryable;

@Retryable(value = {ThirdPartyPaymentException.class}, maxAttempts = 3, backoff = @Backoff(delay = 2000))
public void pay(Order order) {
 try {
 // 调用第三方支付接口
 thirdPartyPaymentService.pay(order.getAmount());
 // 更新订单状态为已支付
 order.setStatus(OrderStatus.PAID);
 } catch (ThirdPartyPaymentException e) { // 自定义异常，表示第三方支付服务异常
 logger.error("支付失败：", e);
 throw new ThirdPartyPaymentException("第三方支付失败", e); // 保留原始异常信息
 } catch (NetworkException e) { // 网络异常，进行重试
 logger.warn("网络异常，正在重试：", e);
 throw e;
 } catch (IllegalArgumentException e) { // 参数错误，直接返回错误信息
 logger.error("参数错误：", e);
 throw new BusinessException("参数错误", e);
 }
}

// 自定义异常
public class ThirdPartyPaymentException extends Exception {
 public ThirdPartyPaymentException(String message, Throwable cause) {
 super(message, cause);
 }
}

在这个例子中，我们使用了 Spring Retry 框架来实现重试机制。通过 @Retryable 注解，我们可以指定需要重试的异常类型、最大重试次数和重试间隔。我们还自定义了一个 ThirdPartyPaymentException 异常，用于表示第三方支付服务异常。在 catch 块中，我们保留了原始异常的信息，方便问题排查。

此外，还可以考虑使用 AOP 来统一处理异常。例如，可以定义一个切面，拦截所有标注了特定注解的方法，并在方法执行过程中捕获异常，进行统一的日志记录、告警等处理。这可以有效地减少代码的重复，提高代码的可维护性。

4. 实战避坑经验总结

• 避免过度捕获异常：尽量精确地捕获异常，避免使用 catch (Exception e) 捕获所有异常。
• 保留原始异常信息：在抛出新的异常时，将原始异常作为参数传入，保留原始异常的信息。
• 谨慎使用已选中异常：权衡利弊，避免过度使用已选中异常，增加代码的复杂度。
• 善用自定义异常：针对特定的业务场景，可以自定义异常类型，更好地表达业务含义。
• 考虑使用重试机制：对于偶发的异常，引入重试机制，提高系统的可用性。
• 统一异常处理：使用 AOP 等技术，统一处理异常，减少代码的重复，提高代码的可维护性。

在实际项目中，根据具体的业务场景选择合适的例外处理方式，是保证系统稳定性和可维护性的关键。合理运用已选中、未选中和自定义异常，可以帮助我们构建更加健壮的 Java 后端系统。例如，在高并发场景下，使用 Nginx 作为反向代理服务器，通过配置 upstream 实现负载均衡，可以有效分散请求压力。如果后端服务出现故障，Nginx 可以及时切换到其他健康的服务器，保证服务的可用性。同时，Nginx 还可以配置健康检查机制，定期检查后端服务的状态，及时发现并处理故障。利用宝塔面板可以更方便地管理 Nginx 的配置，监控服务器的运行状态，例如 CPU 使用率、内存占用率、并发连接数等，及时发现潜在的问题。