在基于SpringBoot的Web应用中,对于Http请求处理过程中发生的各种错误,如常见的400、404和500等错误,SpringBoot默认提供了一种映射到错误页面/error
的机制来处理所有的错误,并且该页面也由SpringBoot默认提供,不需要开发者自己编写。该页面会显示请求的错误状态码, 以及一些错误原因和消息,如下图分别为SpringBoot默认提供的404错误和500错误页面:
上述/error
错误页面路径可以理解为SpringBoot默认为我们写了一个模版错误页面,然后默认还写了一个Controller
,该Controller
中包含一个/error
请求地址映射指向该错误页面。当SpringBoot的错误处理机制捕获到请求异常之后,则会将用户的原请求携带上错误信息,然后转发到这个/error
页面,页面再显示错误的相关信息。
虽然SpringBoot提供了默认的错误显示页面,但是仅使用该默认错误页面会存在大量的局限性:
基于上述SpringBoot默认错误处理机制存在的局限性和问题,SpringBoot中提供了@ControllerAdvice
和@ExceptionHandler
两个注解来实现专门对服务器500异常进行自定义处理。使用示例如下:
@ControllerAdvice
public class ExceptionController {
@ExceptionHandler(Exception.class)
@ResponseBody
public Map globalException(HttpServletRequest request, Exception e) {
Map<String,Object> map = new HashMap<>();
map.put("code",500);
map.put("message",e.getMessage());
return map;
}
@ExceptionHandler(MyException.class)
@ResponseBody
public Map myException(HttpServletRequest request, Exception e) {
Map<String,Object> map = new HashMap<>();
map.put("code",500);
map.put("message",e.getMessage());
return map;
}
}
@ControllerAdvice
注解表示我们定义的是一个控制器增强类,当其他任何控制器发生异常且异常类型符合@ExceptionHandler
注解中指定的异常类时,原请求将会被拦截到这个我们自定义的控制器方法中。
在该方法中,我们可以拿到异常信息,于是便可以自定义该如何处理异常,是返回一个我们自定义的模版错误页面,还是返回JSON数据,这将都由我们根据实际应用场景而自己决定。并且我们还可以自定义异常类处理特殊情况。
另外,@ExceptionHandler
注解只有一个value
参数,为指定的异常类;@ControllerAdvice
注解查看源码参数发现我们还可以指定需要拦截的控制器所在的包路径
。
在业务控制器中模拟发生异常:
@GetMapping("user/{id}")
public User findById(@PathVariable("id") Long id) {
User user = userService.findById(id);
int i = 1/0;
return user;
}
上述通过注解实现的控制器增强类虽然可以处理所有异常对应的500错误,但是对于404等错误,却没法捕获和处理。
实际上,在上文提到的SpringBoot默认错误处理机制中,完成任务处理的控制器实际上是SpringBoot在自动配置类中注入的BasicErrorController
对象,该类继承AbstractErrorController
,而AbstractErrorController
又实现了ErrorController
接口。
所以其实如果我们自定义一个BasicErrorController
控制器,则Spring容器将不会再使用默认提供的BasicErrorController
控制器,转而使用我们自定义的错误处理控制器。
自定义我们自己的BasicErrorController
控制器,可以像默认的BasicErrorController
一样直接继承AbstractErrorController
,甚至可以直接照搬BasicErrorController
的代码,根据自己需求做修改即可。如下示例为我自定义的error
处理方法,能够获取了一些错误的基本信息,对常规的错误处理和日志记录已经足够:
@Slf4j
@RestController
@Slf4j
@RestController
public class HttpErrorController extends AbstractErrorController {
private final static String ERROR_PATH = "/error";
public HttpErrorController(ErrorAttributes errorAttributes) {
super(errorAttributes);
}
@Override
public String getErrorPath() {
return ERROR_PATH;
}
@RequestMapping(ERROR_PATH)
public Map error(HttpServletRequest request, HttpServletResponse response){
Map<String, Object> attributes = getErrorAttributes(request, true);
//获取日志需要的请求url和详细堆栈错误信息
String path = attributes.get("path").toString();
String trace = attributes.get("trace").toString();
log.error("path:{} trace:{}",path, trace);
//获取错误时间、状态码和错误描述信息,返回给用户
Date timestamp = (Date) attributes.get("timestamp");
Integer status = (Integer) attributes.get("status");
String error = attributes.get("error").toString();
Map<String, Object> map = new HashMap<>();
map.put("code",status);
map.put("message",error);
map.put("timestamp",timestamp);
return map;
}
}
我们也可以直接实现ErrorController
类来对默认BasicErrorController
控制器进行替换。但是由于ErrorController
接口只有一个过时了的方法,没有AbstractErrorController
类提供的一些获取错误信息的方法,所以这种方式只能捕获到所有错误,但是不能获取错误的详细信息。
@RestController
public class HttpErrorController implements ErrorController {
private final static String ERROR_PATH = "/error";
@Override
public String getErrorPath() {
return ERROR_PATH;
}
@RequestMapping(ERROR_PATH)
public Map error(HttpServletRequest request, HttpServletResponse response){
Map<String,Object> map = new HashMap<>();
map.put("code","4xx");
map.put("message","请求错误~");
return map;
}
}
实现ErrorController
接口需要实现getErrorPath()
方法,返回的路径表示服务器将会重定向到该路径对应的控制器类,本例中为error
方法。
测试404错误示例效果:
因此对于这种方式,一般推荐和上文第一种@ControllerAdvice
+@ExceptionHandler
注解的方式结合起来使用:
@ControllerAdvice
声明的增强控制器专门负责对服务器内部异常的500错误进行处理;ErrorController
接口的这个错误处理控制器专门处理增强控制器不能捕获到的其他404等错误。这两种方式一起使用并不会冲突,@ControllerAdvice
声明的增强控制器会优先捕获异常,不能捕获的部分再由ErrorController
接口的实现类处理即可。
上述的方式看上去已经可以处理几乎所有的错误了。但是,由于上述捕获错误方式原理是在控制器,即本质是在Servlet中,所以如果错误是发生在Filter
过滤器中,那么错误将可能没法捕获和处理,因为过滤器处理请求的顺序是优先Servlet的,如果在过滤器中讲请求拦截了中断了,则后续SpringBoot中的错误处理机制将无法捕获错误和处理。
所以对于过滤器Filter
中的部分错误,仍需要自己手动根据实际需求处理。