优雅处理应用异常：全局异常处理器的设计与实践

在微服务架构日渐流行的今天，构建一个健壮、可靠的应用至关重要。而全局异常处理器，正是保障系统稳定运行，提升用户体验的关键组件之一。试想一下，当用户正在进行支付操作，突然遇到一个服务器内部错误，如果没有妥善处理，可能会导致订单丢失，用户流失。良好的全局异常处理机制，可以捕获这些未预期的错误，并以友好的方式告知用户，同时记录详细的错误日志，方便后续排查。

异常处理的必要性与常见问题

一个完善的异常处理体系，应当覆盖应用中的各个层面，包括但不限于：

• 框架层面：Spring Boot 等框架提供的默认异常处理机制，通常只适用于简单的场景。
• 业务逻辑层面：在 Service 层对可能出现的业务异常进行捕获和处理。
• 数据访问层面：处理数据库连接异常、SQL 异常等。
• 外部接口调用层面：处理第三方 API 调用失败的情况，例如调用微信支付 API 失败。

然而，在实际开发中，我们常常会遇到以下问题：

1. 异常处理逻辑分散：代码中充斥着大量的 try-catch 块，冗余且难以维护。
2. 异常信息不统一：不同的模块返回的错误信息格式不一致，给前端造成困扰。
3. 忽略关键异常：某些异常没有被捕获，导致系统崩溃或数据丢失。
4. 过度包装异常：将底层异常包装成自定义异常，但丢失了原始异常的信息。

全局异常处理器的原理与优势

全局异常处理器通过拦截未被捕获的异常，并进行统一的处理，从而解决上述问题。其核心原理通常是利用 AOP（面向切面编程）或框架提供的拦截器机制。例如，在 Spring Boot 中，我们可以使用 @ControllerAdvice 和 @ExceptionHandler 注解来实现全局异常处理。

全局异常处理器的优势：

• 统一异常处理逻辑：将所有异常处理逻辑集中到一个地方，方便维护和管理。
• 统一异常返回格式：定义统一的错误码和错误信息格式，提高前后端协作效率。
• 增强系统健壮性：防止未处理的异常导致系统崩溃。
• 提高代码可读性：减少代码中的 try-catch 块，使代码更加简洁易懂。

基于 Spring Boot 的全局异常处理实践

下面是一个基于 Spring Boot 的全局异常处理器的示例：

import org.springframework.http.HttpStatus;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.ControllerAdvice;
import org.springframework.web.bind.annotation.ExceptionHandler;
import org.springframework.web.bind.annotation.ResponseBody;

import javax.servlet.http.HttpServletRequest;
import java.util.HashMap;
import java.util.Map;

@ControllerAdvice // 定义全局异常处理类
public class GlobalExceptionHandler {

    @ExceptionHandler(value = Exception.class) // 捕获所有 Exception 类型的异常
    @ResponseBody
    public ResponseEntity<Map<String, Object>> defaultErrorHandler(HttpServletRequest req, Exception e) throws Exception {
        Map<String, Object> response = new HashMap<>();
        response.put("code", 500); // 自定义错误码
        response.put("message", "服务器内部错误: " + e.getMessage()); // 错误信息
        response.put("data", null);

        // 打印异常堆栈信息，方便排查问题
        e.printStackTrace();

        return new ResponseEntity<>(response, HttpStatus.INTERNAL_SERVER_ERROR); // 返回 500 状态码
    }

    @ExceptionHandler(value = BusinessException.class) // 捕获自定义业务异常
    @ResponseBody
    public ResponseEntity<Map<String, Object>> businessExceptionHandler(HttpServletRequest req, BusinessException e) throws Exception {
        Map<String, Object> response = new HashMap<>();
        response.put("code", e.getCode()); // 使用业务异常中的错误码
        response.put("message", e.getMessage()); // 使用业务异常中的错误信息
        response.put("data", e.getData()); // 业务数据

        return new ResponseEntity<>(response, HttpStatus.BAD_REQUEST); // 返回 400 状态码
    }
}

// 自定义业务异常
class BusinessException extends RuntimeException {
    private int code;
    private Object data;

    public BusinessException(int code, String message, Object data) {
        super(message);
        this.code = code;
        this.data = data;
    }

    public int getCode() {
        return code;
    }

    public Object getData() {
        return data;
    }
}

在这个示例中，@ControllerAdvice 注解标记该类为全局异常处理类，@ExceptionHandler 注解用于指定处理特定类型的异常的方法。我们可以根据实际需求，定义多个 @ExceptionHandler 方法，分别处理不同类型的异常。例如，可以专门处理数据库异常、网络异常等。

异常信息格式规范

{
  "code": 500,  // 错误码
  "message": "服务器内部错误: xxx", // 错误信息
  "data": null // 可选的业务数据
}

实战避坑与经验总结

1. 避免过度捕获异常：只捕获你能够处理的异常，不要捕获所有异常而不做任何处理。这会导致隐藏真正的错误，给调试带来困难。
2. 合理使用自定义异常：自定义异常应该只用于表示特定的业务场景，不要过度使用。如果只是为了简单地包装异常，不如直接抛出原始异常，并记录详细的日志信息。
3. 记录详细的错误日志：在全局异常处理器中，务必记录详细的错误日志，包括异常类型、错误信息、请求参数、用户 ID 等。这对于后续排查问题至关重要。 可以结合 logback 或者 log4j2 等日志框架，方便配置和管理日志。
4. 考虑熔断和降级机制: 在微服务架构中，如果依赖的服务出现故障，可能会导致整个系统雪崩。因此，需要考虑使用熔断和降级机制，例如 Hystrix 或 Resilience4j，来提高系统的可用性。同时，全局异常处理器可以配合这些框架，统一处理熔断和降级引发的异常。
5. 注意事务回滚：如果异常发生在事务中，确保事务能够正确回滚。Spring 的 @Transactional 注解可以帮助我们实现事务管理。
6. 监控与告警: 对系统异常进行监控，并通过邮件、短信等方式进行告警。可以使用 Prometheus 和 Grafana 等工具来实现监控和告警。

综上所述，全局异常处理是构建健壮应用的重要环节。通过合理的异常处理策略，可以提高系统的可用性、可维护性和用户体验。希望本文能够帮助你更好地理解和应用全局异常处理技术。