简概

官方文档地址： HTML /web.html#mvc-ann- Exception handler

异常处理⽅法

• 处理⽅法

• @Exception handler

• 添加位置

• @Controller / @RestController
• @ControllerAdvice / @RestControllerAdvice

1. @RestControllerAdvice或者@ControllerAdvice类内的解析器的优先级低于@ Controller或@RestController 类的解析器的优先级
2. 如果一个异常能被多个解析器所处理，则选择继承关系最近的解析器

异常处理方法-@ExceptionHandler

@Controller和@ControllerAdvice类可以有@ExceptionHandler方法来处理来自 控制器 方法的异常，如下例所示:

 @Controller
public class SimpleController {

    // ...

    @Exception handle r
    public ResponseEntity<String> handle(IOException ex) {
        // ...
    }
}  

异常可以匹配正在传播的顶级异常(例如抛出的直接IOException)，也可以匹配包装器异常中的嵌套原因(例如包裹在Illegal State Exception中的IOException)。 在5.3中，这可以匹配任意的原因级别，而以前只考虑直接原因 。

为了匹配异常类型，最好将目标异常声明为方法参数 ，如上例所示。当多个异常方法匹配时，根异常匹配通常优先于原因异常匹配。更具体地说， ExceptionDepthComparator用于根据抛出异常类型的深度对异常进行排序 。

或者，通过注解的声明来缩小异常类型以匹配，如下例所示:

 @ExceptionHandler({FileSystemException.class, RemoteException.class})
public ResponseEntity<String> handle(IOException ex) {
    // ...
}  

甚至可以使用一个带有非常通用的参数签名的特定异常类型列表，如下例所示:

 @ExceptionHandler({FileSystemException.class, RemoteException.class})
public ResponseEntity<String> handle(Exception ex) {
    // ...
}  

根源异常和原因异常匹配之间的区别可能令人惊讶。

在前面展示的IOException变体中，通常使用实际的FileSystemException或RemoteException实例作为参数调用该方法，因为它们都是从IOException扩展而来的。但是，如果任何这样的匹配异常在包装器异常中传播，而包装器异常本身就是一个IOException，则传入的异常实例就是那个包装器异常。

在 handle (Exception)变体中，这种行为甚至更简单。在包装场景中，这总是与包装器异常一起调用，在这种情况下，通过ex.getCause()找到实际匹配的异常。传入的异常只有在作为顶级异常抛出时才是实际的FileSystemException或RemoteException实例。

通常建议在参数签名中尽可能具体，以减少根源异常类型和原因异常类型之间不匹配的可能性。 考虑将多匹配方法分解为单独的@ExceptionHandler方法，每个方法通过其签名匹配单个特定的异常类型。

在多个@ControllerAdvice中，建议按相应顺序优先级排列的@ControllerAdvice上声明主根异常映射。虽然根异常匹配优先于原因，但这是在一个给定 controller 或@ControllerAdvice类的方法中定义的。这也就是说 高优先级的@ControllerAdvice Bean 上的原因匹配优先于低优先级的@ControllerAdvice bean上的任何匹配 (例如，根)。

最后但并非最不重要的是，@ExceptionHandler方法实现可以通过以原始形式重新抛出给定异常实例来选择退出处理。如果您只对根级匹配感兴趣，或者对无法静态确定的特定上下文中的匹配感兴趣，那么这将非常有用。 重新抛出的异常通过剩余的解析链传播，就好像给定的@ExceptionHandler方法一开始就不匹配一样 。

Spring MVC 中对@ExceptionHandler方法的支持是建立在DispatcherServlet级别、HandlerExceptionResolver机制上的。

Controller Advice

官网文档：#mvc-ann-controller-advice

@ExceptionHandler、@ Init Binder和@ModelAttribute三个注解标记的方法只作用于声明它们的@Controller 类 或类层次结构。而 如果它们在@ControllerAdvice或@RestControllerAdvice类中声明，那么它们将应用于任何controller 。从5.3开始，@ControllerAdvice中的@ExceptionHandler方法可以用于处理来自任何@Controller或任何其他处理程序的异常。

@ControllerAdvice使用@Component进行元注释，因此可以通过组件扫描注册为 spring bean。@RestControllerAdvice使用@ControllerAdvice和@ResponseBody进行元注释，这意味着@ExceptionHandler方法的返回值将通过响应体消息转换呈现，而不是通过HTML视图。

在启动时， Request MappingHandlerMapping和ExceptionHandlerExceptionResolver检测 controller advice beans 并在运行时应用它们。来自@ControllerAdvice的全局@ExceptionHandler方法应用在来自@Controller的本地方法之后。相比之下，全局的@ModelAttribute和@InitBinder方法在本地方法之前被应用。

@ControllerAdvice注解具有一些属性，可以缩小@ControllerAdvice注解所应用的控制器和处理程序集。

但其是在运行时计算，如果广泛使用，可能会对性能产生负面影响。

@InitBinder

@InitBinder 用于在控制器( Controller) 中标注于方法上，表示为当前控制器注册一个属性编辑器，只对当前的Controller有效。 @InitBinder 标注的方法必须有一个参数 WebDataBinder 。webDataBinder是用于表单到方法的数据绑定的。所谓的属性编辑器可以理解就是帮助我们完成参数绑定。

可参考：

@ModelAttribute

@ModelAttribute，用来将请求参数绑定到 Model 对象。
需要注意的是，因为模型对象要先于 controller 方法之前创建，所以 被 @ModelAttribute 注解的方法会在 Controller 每个方法执行之前都执行 。因此 一个 Controller 映射多个 URL 时，要谨慎使用 。

可参考：

@Exception Handler 支持的方法参数

@ExceptionHandler支持的方法返回值