spring异常分析及处理

spring异常分析及处理

spring mvc exceptions

参考官方文档：https://docs.spring.io/spring/docs/5.2.7.RELEASE/spring-framework-reference/web.html#mvc-exceptionhandlers

如果异常在请求映射期间发生或从请求处理程序（例如@Controller）抛出，则DispatcherServlet委托给HandlerExceptionResolver Beans 来解决该异常并提供替代处理，通常是错误响应。

下表列出了可用的HandlerExceptionResolver实现：

HandlerExceptionResolver	描述
SimpleMappingExceptionResolver	异常类名称和错误视图名称之间的映射。对于在浏览器应用程序中呈现错误页面很有用。
DefaultHandlerExceptionResolver	解决Spring MVC引发的异常，并将它们映射到HTTP状态代码。另请参见替代ResponseEntityExceptionHandler和REST API异常。
ResponseStatusExceptionResolver	使用@ResponseStatus注释解决异常，并根据注释中的值将其映射到HTTP状态代码。
ExceptionHandlerExceptionResolver	通过调用@Controller或@ControllerAdvice类中的@ExceptionHandler方法来解决异常。请参见@ExceptionHandler方法。

支持的Exceptions

javax.servlet.http.HttpServletResponse

Exception	HTTP Status Code
HttpRequestMethodNotSupportedException	405 (SC_METHOD_NOT_ALLOWED)
HttpMediaTypeNotSupportedException	415 (SC_UNSUPPORTED_MEDIA_TYPE)
HttpMediaTypeNotAcceptableException	406 (SC_NOT_ACCEPTABLE)
MissingPathVariableException	500 (SC_INTERNAL_SERVER_ERROR)
MissingServletRequestParameterException	400 (SC_BAD_REQUEST)
ServletRequestBindingException	400 (SC_BAD_REQUEST)
ConversionNotSupportedException	500 (SC_INTERNAL_SERVER_ERROR)
TypeMismatchException	400 (SC_BAD_REQUEST)
HttpMessageNotReadableException	400 (SC_BAD_REQUEST)
HttpMessageNotWritableException	500 (SC_INTERNAL_SERVER_ERROR)
MethodArgumentNotValidException	400 (SC_BAD_REQUEST)
MissingServletRequestPartException	400 (SC_BAD_REQUEST)
BindException	400 (SC_BAD_REQUEST)
NoHandlerFoundException	404 (SC_NOT_FOUND)
AsyncRequestTimeoutException	503 (SC_SERVICE_UNAVAILABLE)

Chain of Resolvers

您可以通过HandlerExceptionResolver 在Spring配置中声明多个bean并order根据需要设置它们的属性来形成异常解析器链。order属性越高，异常解析器的定位就越晚。

HandlerExceptionResolver 接口定义了方法：

ModelAndView resolveException(
			HttpServletRequest request, HttpServletResponse response, @Nullable Object handler, Exception ex);

HandlerExceptionResolver中定义指定它可以返回：

• 指定错误视图的ModelAndView.
• 如果在程序解析中处理了异常，则为空的ModelAndView (return new ModelAndView())。
• 如果该异常仍未解决，则为null，以供后续的解析器尝试；如果该异常仍在末尾，则允许将其冒泡到Servlet容器。

MVC Config 默认自动声明了内置的 spring MVC 异常解析器，对于带注释@ResponseStatus的异常, 和@ExceptionHandler方法的支持。您可以自定义列表或取代它。

Container Error Page

如果任何HandlerExceptionResolver异常仍未得到解决,因此,造成传播或如果响应状态设置为一个错误状态( 4xx, 5xx), Servlet容器可以在HTML渲染一个默认的错误页面。自定义容器的默认错误页面,您可以在web . xml中声明一个错误页面映射。下面的例子显示了如何这样做:

<error-page>
    <location>/error</location>
</error-page>

鉴于前面的例子,当一个异常冒泡或响应错误状态时,Servlet容器将产生的错误发送到容器内配置的URL(例如,/error)。然后由DispatcherServlet处理,可能映射到一个@controller,可实现返回一个错误视图的名字与一个model或呈现JSON响应,如以下示例所示:

@RestController
public class ErrorController {

    @RequestMapping(path = "/error")
    public Map<String, Object> handle(HttpServletRequest request) {
        Map<String, Object> map = new HashMap<String, Object>();
        map.put("status", request.getAttribute("javax.servlet.error.status_code"));
        map.put("reason", request.getAttribute("javax.servlet.error.message"));
        return map;
    }
}

注意：

Servlet API没有提供在Java中创建错误页面映射的方法。但是，您可以同时使用WebApplicationInitializer和web.xml。

常见的异常全局处理

在Spring中常见的全局异常处理，主要有三种：

（1）注解ExceptionHandler

（2）继承HandlerExceptionResolver接口

（3）注解ControllerAdvice

具体可参考：https://www.cnblogs.com/yixinjishu/p/10863529.html

这里我们以HTTP Status Code 400 和 500 作为例子进行演示，我们创建一个Controller类，如下

@RestController
@RequestMapping("echo")
public class EchoController {

    /**
     * 请求路径 http://localhost:端口/echo/get
     *
     * @param name
     * @return
     */
    @RequestMapping("get")
    public String get(@RequestParam("name") String name) {
        return "response：" + name;
    }

    /**
     * 请求路径 http://localhost:端口/echo/cal
     *
     * @return
     */
    @RequestMapping("cal")
    public int calculate() {
        int val = 100 / 0;
        return val;
    }
}

我们分别请求get和cal 返回的错误分别对应400 和 500 如下：

注解@ExceptionHandler

注解ExceptionHandler作用对象为方法，最简单的使用方法就是放在controller文件中，详细的注解定义不再介绍。如果项目中有多个controller文件，通常可以在baseController中实现ExceptionHandler的异常处理，而各个contoller继承basecontroller从而达到统一异常处理的目的。因为比较常见，简单代码在上面添加如下代码：

@ExceptionHandler(Exception.class)
public String exception(Exception e) {
	return this.getClass().getSimpleName() + ":" + e.getMessage();
}

这时候在分别请求get和cal 返回的信息如下：

EchoController:Required String parameter 'name' is not present

EchoController:/ by zero

这时候发现添加ExceptionHandler之后的结果

优点：ExceptionHandler简单易懂，并且对于异常处理没有限定方法格式；

缺点：由于ExceptionHandler仅作用于方法，对于多个controller的情况，仅为了一个方法，所有需要异常处理的controller都继承这个类，不太好。

注解@ControllerAdvice

@ControllerAdvice注解，其实是其与ExceptionHandler的组合使用。在上文中可以看到，单独使用@ExceptionHandler时，其必须在一个Controller中，然而当其与ControllerAdvice组合使用时就完全没有了这个限制。换句话说，二者的组合达到的全局的异常捕获处理，我们创建一个类GlobalExceptionHandler，然后把上面EchoController的exception方法整个注释掉，这时候在请求get和cal 返回的信息和单独用注解ExceptionHandler一致。

@ControllerAdvice
public class GlobalExceptionHandler {

    @ExceptionHandler(Exception.class)
    @ResponseBody
    public String exception(Exception e) {
        return this.getClass().getSimpleName() + ":" + e.getMessage();
    }
}

通过上面结果可以看到，异常处理确实已经变更为GlobalExceptionHandler类。这种方法将所有的异常处理整合到一处，去除了Controller中的继承关系，并且达到了全局捕获的效果，推荐使用此类方式。

实现HandlerExceptionResolver接口

HandlerExceptionResolver本身是SpringMVC内部的接口，其内部只有resolveException一个方法，通过实现该接口我们可以达到全局异常处理的目的。

我们创建一个类：MyHandlerExceptionResolver，同时将GlobalExceptionHandler类上的注解@ControllerAdvice注释掉。

@Component
public class MyHandlerExceptionResolver implements HandlerExceptionResolver {
    @Override
    public ModelAndView resolveException(HttpServletRequest request, 
                                         HttpServletResponse response,
                                         Object handler, Exception ex) {
        String message = this.getClass().getSimpleName() + ":" + ex.getMessage();
        PrintWriter pw = null;
        try {
            pw = response.getWriter();
            pw.write(message);
            pw.flush();
        } catch (IOException e) {
            e.printStackTrace();
        } finally {
            if (null != pw) {
                pw.close();
            }
        }
        return new ModelAndView();
    }
}

但这里有一个问题请求get时没有生效，显示错误信息如下

为什么500的异常处理已经生效了，但是400的异常处理却没有生效。这是怎么回事呢？不是说可以达到了全局捕获的效果吗？这里只好跟踪Spring的源码进行分析。

Spring中异常处理源码分析

在DispatcherServlet 类中的方法doDispatch 中调用了processDispatchResult方法，processDispatchResult调用了processHandlerException方法，如下图1：

​ 图1

​ 图2

看方法processHandlerException的代码this.handlerExceptionResolvers包含3个HandlerExceptionResolver【DefaultErrorAttributes，HandlerExceptionResolverComposite，MyHandlerExceptionResolver】。在循环到HandlerExceptionResolverComposite时跳出了循环，说明了异常被Spring自带的异常给处理掉了，所以就跳过了MyHandlerExceptionResolver类的处理，从而出现400的返回结果。而对于add请求，中间没有阻拦，所以就达到了预期效果。

三类异常的处理顺序

先把结论写上在进行分析：@ExceptionHandler优先于@ControllerAdvice优先于HandlerExceptionResolver。

我们将EchoController、GlobalExceptionHandler类上面的注释的内容全部放开。

下面去Spring源码去找结论，上面提到了HandlerExceptionResolverComposite 它里面有3个HandlerExceptionResolver分别是【ExceptionHandlerExceptionResolver，ResponseStatusExceptionResolver，DefaultHandlerExceptionResolver】,如下图3：

图3

ExceptionHandlerExceptionResolver中的doResolveHandlerMethodException方法中调用了getExceptionHandlerMethod方法如下图4：

​ 图4

通过跟进，发现有两个变量可能就是问题的关键：exceptionHandlerCache和exceptionHandlerAdviceCache。首先，exceptionHandlerCache上面的注释的翻译过来意思为:

// Local exception handler methods on the controller class itself.
// 控制器类本身上的本地异常处理程序方法。
// To be invoked through the proxy, even in case of an interface-based proxy.
// 即使是基于接口的代理，也要通过代理调用。
handlerType = handlerMethod.getBeanType();
ExceptionHandlerMethodResolver resolver = this.exceptionHandlerCache.get(handlerType);

​ 图5

在看代码上面的method正是@ExceptionHandler标注的EchoController方法exception相吻合。而在往下的代码

是针对@ControllerAdvice 注解进行处理的逻辑，然后在结合上面分析的HandlerExceptionResolver所处HandlerExceptionResolver的索引已知，参考图1。所以得出接口@ExceptionHandler优先于@ControllerAdvice优先于HandlerExceptionResolver。

for (Map.Entry<ControllerAdviceBean, ExceptionHandlerMethodResolver> entry : this.exceptionHandlerAdviceCache.entrySet()) {
			ControllerAdviceBean advice = entry.getKey();
			if (advice.isApplicableToBeanType(handlerType)) {
				ExceptionHandlerMethodResolver resolver = entry.getValue();
				Method method = resolver.resolveMethod(exception);
				if (method != null) {
					return new ServletInvocableHandlerMethod(advice.resolveBean(), method);
				}
			}
		}