一、引言
本篇内容是“异常统一处理”系列文章的重要组成部分,主要聚焦于对 Exception(兜底异常)
的原理解析与异常处理机制,并给出测试案例。
- 关于 全局异常统一处理 的原理和完整实现逻辑,请参考文章:
《SpringBoot 全局异常统一处理(AOP):@RestControllerAdvice + @ExceptionHandler + @ResponseStatus》- 本文仅详细解析 Throwable(兜底异常) 的异常处理;其他类型异常的原理和处理方法,请参阅本文所在专栏内的其他文章。
二、异常原理
SpringBoot项目,异常统一处理,是否应该有兜底异常?
在Spring Boot项目中,异常统一处理是非常重要的一部分,确保系统能够以一致且用户友好的方式响应各种运行时错误。确实应该设计一个兜底异常处理器,它通常用来捕获那些没有被具体异常处理器所处理的任何未预期或未知的异常。
兜底异常处理器(Fallback Exception Handler) 的作用在于:
-
全面覆盖:当出现没有明确指定的异常类型时,兜底异常处理器可以捕获所有未被捕获的异常。
-
友好提示:对于这类无法预知的具体问题,兜底异常处理器通常会返回一个通用的错误信息给客户端,避免暴露过多服务器内部细节。
-
日志记录:在处理这些异常时,通常还会进行详细的日志记录,这对于后续排查问题至关重要。
-
业务连续性:在某些场景下,兜底异常处理器还可能包含重试机制、熔断策略或者降级服务,以保证系统的健壮性和可用性。
在Spring Boot中实现兜底异常处理的方式是在带有@ControllerAdvice
注解的全局异常处理类中定义一个处理Exception
的方法,并使用@ExceptionHandler(Exception.class)
注解该方法。通过这种方式,无论哪种未处理的异常发生,都会触发这个兜底异常处理器来进行集中处理。
三、异常处理代码
3.1 异常处理示意图
3.2 异常处理核心代码
package com.example.core.advice;
import com.example.core.model.Result;
import lombok.extern.slf4j.Slf4j;
import org.springframework.http.HttpStatus;
import org.springframework.web.bind.annotation.ExceptionHandler;
import org.springframework.web.bind.annotation.ResponseStatus;
import org.springframework.web.bind.annotation.RestControllerAdvice;
import org.springframework.web.method.HandlerMethod;
/**
* 全局异常处理器
*/
@Slf4j
@RestControllerAdvice
public class GlobalExceptionHandler {
private static final String USER_TIP = "服务器异常!请稍后重试,或联系业务人员处理。";
/**
* 兜底异常处理。
* <p>
* 作为最后兜底的异常处理,不应该将异常信息的细节返回给前端;
* 因为异常信息中可能会包含一些敏感信息,比如SQL报错可能会包含数据库的表名、字段名和SQL语句,将这些暴露给用户存在安全性风险。
*/
@ExceptionHandler
@ResponseStatus(HttpStatus.INTERNAL_SERVER_ERROR)
public Result<String> handle(Exception e, HandlerMethod handlerMethod) {
// 记录错误日志
log.error("发生了一个未预期的异常", e);
// 返回统一的错误响应给前端。
return Result.fail(USER_TIP, String.valueOf(HttpStatus.INTERNAL_SERVER_ERROR.value()), null);
}
}
四、测试案例
4.1 测试代码
package com.example.web.exception.controller;
import io.swagger.v3.oas.annotations.Operation;
import io.swagger.v3.oas.annotations.Parameter;
import io.swagger.v3.oas.annotations.enums.ParameterIn;
import io.swagger.v3.oas.annotations.tags.Tag;
import lombok.extern.slf4j.Slf4j;
import org.springframework.lang.Nullable;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;
@Slf4j
@RestController
@RequestMapping("exception")
@Tag(name = "异常统一处理")
public class ExceptionController {
@GetMapping("fallback_exception")
@Parameter(name = "input", description = "输入参数", example = "张三", in = ParameterIn.QUERY)
@Operation(summary = "兜底异常", description = "当 input 为空时,抛出异常。")
public String testFallbackException(@Nullable String input) {
// IDE在此处给出警告;这是为了测试,特意留下来的。
String lowerCaseInput = input.toLowerCase();
log.info("lowerCaseInput = {}", lowerCaseInput);
return "成功";
}
}
4.2 正确请求示例
4.3 未处理异常时的报错
请求响应
控制台的错误日志
4.4 已处理异常时的响应
五、相关问题
(1)异常统一处理,是否应该有兜底异常?
我认为应该有兜底异常。详细解释请参考如下文章。
参考文章:《异常处理:全面覆盖与精细化管理的平衡》
(2)Exception和Throwable,哪个更合适?
在Java中,所有异常都是Throwable
类的子类。Throwable
是Java中所有错误或异常的超类,它有两个直接子类:Error
和Exception
。
-
Error
是程序无法处理的错误,通常表示运行时环境的错误,如系统崩溃、虚拟机错误(如OutOfMemoryError
)等,应用程序一般不应捕获这类错误进行处理。 -
Exception
则是程序可以捕获并进行处理的异常,包括了检查型异常(如IOException
)和运行时异常(如NullPointerException
)等。
在设计Spring Boot项目全局兜底异常处理器时,通常选择捕获Exception
更为合适,而非Throwable
。原因如下:
-
业务相关性:
Exception
涵盖了所有可能在业务逻辑中抛出并需要处理的异常情况,而Error
通常是不应该被捕获并在应用层处理的。 -
避免处理不合适的错误:捕获
Throwable
可能会误处理JVM级别的错误,这些错误往往意味着更严重的系统问题,不适合在应用层面进行简单的错误处理和响应,而是应该尽快通知运维人员进行排查。
因此,推荐的做法是在全局异常处理器中使用@ExceptionHandler(Exception.class)
来作为兜底异常处理,例如:
@ControllerAdvice
public class GlobalExceptionHandler {
@ExceptionHandler(value = Exception.class)
public ResponseEntity<?> handleAllExceptions(Exception ex) {
// ...
}
}
这样能确保我们只处理与业务相关的可预期异常,而不涉及JVM级别的内部错误。