成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

Spring MVC 異常解析器，原理就是這么簡單

作者： 李立敏
開發 前端
因為@ExceptionHandler注解的方式已經足夠強大，所以我們一般也很少通過實現HandlerExceptionResolver來自定義異常處理策略。

[[330436]]

使用介紹

一般自定義異常處理策略有兩種方式

  1. 使用@ExceptionHandler注解
  2. 實現HandlerExceptionResolver接口

因為@ExceptionHandler注解的方式已經足夠強大，所以我們一般也很少通過實現HandlerExceptionResolver來自定義異常處理策略。

簡單介紹一下@ExceptionHandler的使用，后面會結合這些例子進行源碼分析

  1. @RestController 
  2. @RequestMapping("location") 
  3. public class LocationController { 
  4.  
  5.  @RequestMapping("getLocationInfo") 
  6.  public String index() { 
  7.   int sum = 10 / 0; 
  8.   return "locationInfo"; 
  9.  } 
  10.  
  11.  @ExceptionHandler(RuntimeException.class) 
  12.  public String processRuntimeException() { 
  13.   return "LocationController -> 發生RuntimeException"; 
  14.  } 
  15.  
  16.  @ExceptionHandler(Exception.class) 
  17.  public String processException() { 
  18.   return "LocationController -> 發生Exception"; 
  19.  } 
  20. } 

訪問如下鏈接，返回結果為

  1. http://localhost:8080/location/getLocationInfo 
  2. LocationController -> 發生RuntimeException 

把processRuntimeException方法注釋掉以后，再次訪問上面的鏈接，結果為

  1. LocationController -> 發生Exception 

如果在每個Controller里面都寫異常解析器還是很麻煩的，能不能在一個地方統一處理異常呢?當然可以，這時候就不得不用到@RestControllerAdvice或者@ControllerAdvice

寫如下的全局異常解析器

  1. @RestControllerAdvice 
  2. public class MyExceptionHandler { 
  3.  
  4.  @ExceptionHandler(RuntimeException.class) 
  5.  public String processRuntimeException() { 
  6.   return "MyExceptionHandler -> 發生RuntimeException"; 
  7.  } 
  8.  
  9.  @ExceptionHandler(Exception.class) 
  10.  public String processException() { 
  11.   return "MyExceptionHandler -> 發生RuntimeException"; 
  12.  } 
  13. } 

訪問上面的鏈接，返回結果為

  1. LocationController -> 發生Exception 

我們把LocationController類的processException方法也注釋掉，此時LocationController類里面已經沒有被@ExceptionHandler注解標記的方法了

訪問上面的鏈接，返回結果為

  1. MyExceptionHandler -> 發生RuntimeException 

把MyExceptionHandler中的processRuntimeException方法注釋掉訪問上面的鏈接，返回結果為

  1. MyExceptionHandler -> 發生Exception 

通過以上的例子，我們可以得出如下結論

 

  1. @RestControllerAdvice或者@ControllerAdvice類內的解析器的優先級低于@RequestMapping類的解析器的優先級
  2. 如果一個異常能被多個解析器所處理，則選擇繼承關系最近的解析器

假設BizException繼承自NullPointException A方法解析BizException B方法解析NullPointException C方法解析Exception

BizException會被A方法解析 NullPointException會被B方法解析 如果沒有A方法，則BizException會被B方法解析，如果B方法也沒有，則被C方法解析，不難理解哈

@RestControllerAdvice和@ControllerAdvice有什么區別呢?

名字上就可以猜出@RestControllerAdvice只是在@ControllerAdvice的基礎上加了@ResponseBody注解，看一波源碼也確實如此。所以@RestControllerAdvice類最終返回的是JSON，@ControllerAdvice最終返回的是視圖。如果你不明白為什么加了@ResponseBody注解最終返回的內容為JSON，建議看一下返回值處理器相關的內容

源碼分析

異常解析器接口定義如下

  1. public interface HandlerExceptionResolver { 
  2.  
  3.  // 將異常封裝為ModelAndView后返回 
  4.  @Nullable 
  5.  ModelAndView resolveException( 
  6.    HttpServletRequest request, HttpServletResponse response,  
  7.    @Nullable Object handler, Exception ex); 
  8.  
  9. } 

Spring MVC默認的異常解析器存放在如下屬性中

  1. @Nullable 
  2. private List<HandlerExceptionResolver> handlerExceptionResolvers; 

順序依次為

 

  • ExceptionHandlerExceptionResolver
  • ResponseStatusExceptionResolver
  • DefaultHandlerExceptionResolver

UML圖如下

Order接口是用來排序的哈，Spring MVC默認的解析器不是通過Order接口來控制順序的，因為默認的解析器都繼承自AbstractHandlerExceptionResolver，并且都沒有重寫getOrder方法

對Spring MVC比較清楚的小伙伴應該都知道DispatcherServlet屬性的默認實現都定義在源碼包的DispatcherServlet.properties文件中，List的順序也是按這個來的。放一部分內容

  1. org.springframework.web.servlet.HandlerAdapter= 
  2.     org.springframework.web.servlet.mvc.HttpRequestHandlerAdapter,\ 
  3.  org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter,\ 
  4.  org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter 
  5.  
  6. org.springframework.web.servlet.HandlerExceptionResolver= 
  7.     org.springframework.web.servlet.mvc.method.annotation.ExceptionHandlerExceptionResolver,\ 
  8.  org.springframework.web.servlet.mvc.annotation.ResponseStatusExceptionResolver,\ 
  9.  org.springframework.web.servlet.mvc.support.DefaultHandlerExceptionReso 

接下來分析這3個默認的HandlerExceptionResolver

ExceptionHandlerExceptionResolver

ExceptionHandlerExceptionResolver用于支持@ExceptionHandler，而@ExceptionHandler應該是我們最常的，方便我們自定義異常處理策略，比通過實現HandlerExceptionResolver接口的方式簡單

從AbstractHandlerMethodExceptionResolver#shouldApplyTo可以看到

  1. @Override 
  2. protected boolean shouldApplyTo(HttpServletRequest request, @Nullable Object handler) { 
  3.  if (handler == null) { 
  4.   // handler為空，交給父類去判斷 
  5.   // 默認該邏輯返回true 
  6.   return super.shouldApplyTo(request, null); 
  7.  } 
  8.  else if (handler instanceof HandlerMethod) { 
  9.   HandlerMethod handlerMethod = (HandlerMethod) handler; 
  10.   handler = handlerMethod.getBean(); 
  11.   // 交給父類判斷 
  12.   return super.shouldApplyTo(request, handler); 
  13.  } 
  14.  else { 
  15.   // 不支持 
  16.   return false; 
  17.  } 
  18. } 

只有當handler為空或者handler的類型為HandlerMethod時(@RequestMapping返回的類型為HandlerMethod)才會執行后面的異常解析邏輯。所以你通過實現Controller接口或者實現HttpRequestHandler接口定義的Handler，這個注解是不起作用的

@ExceptionHandler的處理過程主要和下面2個類有關系ExceptionHandlerExceptionResolver，ExceptionHandlerMethodResolver

用幾個成員變量說一下處理過程，就不貼過多的代碼了

ExceptionHandlerExceptionResolver

  1. // 省略了繼承和實現關系 
  2. public class ExceptionHandlerExceptionResolver { 
  3.  
  4.  @Nullable 
  5.  private HandlerMethodArgumentResolverComposite argumentResolvers; 
  6.  
  7.  @Nullable 
  8.  private HandlerMethodReturnValueHandlerComposite returnValueHandlers; 
  9.  
  10.  private List<HttpMessageConverter<?>> messageConverters; 
  11.  
  12.  
  13.  // 被@RequestMapping標記的類 -> ExceptionHandlerMethodResolver 
  14.  private final Map<Class<?>, ExceptionHandlerMethodResolver>  
  15.  exceptionHandlerCache = new ConcurrentHashMap<>(64); 
  16.  
  17.  // 被@ControllerAdvice注解標記的類 -> ExceptionHandlerMethodResolver 
  18.  private final Map<ControllerAdviceBean, ExceptionHandlerMethodResolver> 
  19.  exceptionHandlerAdviceCache = new LinkedHashMap<>(); 
  20. } 

可以看到ExceptionHandlerExceptionResolver類定義了自己的參數處理器，返回值處理器，消息轉換器。所以你可以通過這些組件反向知道@ExceptionHandler方法支持的參數類型

例如從如下方法可以知道，支持的參數類型為@SessionAttribute，@RequestAttribute等 如果你寫個@RequestParam是肯定不會注入進來的

  1. protected List<HandlerMethodArgumentResolver> getDefaultArgumentResolvers() { 
  2.  List<HandlerMethodArgumentResolver> resolvers = new ArrayList<>(); 
  3.  
  4.  // Annotation-based argument resolution 
  5.  resolvers.add(new SessionAttributeMethodArgumentResolver()); 
  6.  resolvers.add(new RequestAttributeMethodArgumentResolver()); 
  7.  
  8.  // Type-based argument resolution 
  9.  resolvers.add(new ServletRequestMethodArgumentResolver()); 
  10.  resolvers.add(new ServletResponseMethodArgumentResolver()); 
  11.  resolvers.add(new RedirectAttributesMethodArgumentResolver()); 
  12.  resolvers.add(new ModelMethodProcessor()); 
  13.  
  14.  // Custom arguments 
  15.  if (getCustomArgumentResolvers() != null) { 
  16.   resolvers.addAll(getCustomArgumentResolvers()); 
  17.  } 
  18.  
  19.  return resolvers; 
  20. } 

最重要的4個map來了，ExceptionHandlerExceptionResolver的工作過程主要就是操作這4個map

  1. // 省略了繼承和實現關系 
  2. public class ExceptionHandlerExceptionResolver { 
  3.  
  4.  // 被@RequestMapping標記的類 -> ExceptionHandlerMethodResolver 
  5.  private final Map<Class<?>, ExceptionHandlerMethodResolver> 
  6.  exceptionHandlerCache = new ConcurrentHashMap<>(64); 
  7.  
  8.  // 被@ControllerAdvice注解標記的類 -> ExceptionHandlerMethodResolver 
  9.  private final Map<ControllerAdviceBean, ExceptionHandlerMethodResolver> 
  10.  exceptionHandlerAdviceCache = new LinkedHashMap<>(); 
  11.     
  12. } 

exceptionHandlerCache保存了@RequestMapping對應的ExceptionHandlerMethodResolver，是在執行異常解析的過程中被賦值的

exceptionHandlerAdviceCache保存了@ControllerAdvice對應的 ExceptionHandlerMethodResolver，是在ExceptionHandlerExceptionResolver被初始化的過程中賦值的

而ExceptionHandlerMethodResolver你可以認為只是封裝了一下Exception及其對應的Method

以最開始的例子演示，ExceptionHandlerExceptionResolver初始化后

此時exceptionHandlerCache是沒有值的 訪問如下鏈接后

  1. http://localhost:8080/location/getLocationInfo 

exceptionHandlerCache中的值如下，LocationController及其對應的ExceptionHandlerMethodResolver被放了進來追一下以下方法的執行 ExceptionHandlerExceptionResolver#doResolveHandlerMethodException ExceptionHandlerExceptionResolver#getExceptionHandlerMethod

可以得出我們測試的結論@RestControllerAdvice或者@ControllerAdvice類內的解析器的優先級低于@RequestMapping類的解析器的優先級

總體實現也不難，從exceptionHandlerCache中能找到解析器就返回執行，找不到就從exceptionHandlerAdviceCache中找，這不是就實現了優先級了嗎?

接著來看剩下的2個Map

  1. public class ExceptionHandlerMethodResolver { 
  2.  
  3.  
  4.  // 異常 -> 對應的處理方法 
  5.  private final Map<Class<? extends Throwable>, Method> 
  6.  mappedMethods = new HashMap<>(16); 
  7.  
  8.  // 異常 -> 對應的處理方法 
  9.  // 這個是基于mappedMethods又做了一次緩存 
  10.  // 為什么要再做一次緩存呢？ 
  11.  // 是因為根據異常類型獲取處理方法的時候，一個異常可能有多個處理方法，即一個異常會從mappedMethods中查出多個處理方法 
  12.  // 最后返回的是繼承關系最近的異常對應的處理方法，所以在查找的時候又做了一次緩存，避免每次查mappedMethods然后取最優值 
  13.  // 從exceptionLookupCache中就可以直接查到最優的處理方法 
  14.  private final Map<Class<? extends Throwable>, Method> 
  15.  exceptionLookupCache = new ConcurrentReferenceHashMap<>(16); 
  16.   
  17. } 

@ControllerAdvice的mappedMethods是在ExceptionHandlerExceptionResolver初始化的過程中賦值的

@RequestMapping的mappedMethods是在執行異常解析的過程中被賦值的

而exceptionLookupCache是在異常解析過程中，通過Exception查找Method的過程中基于mappedMethods做的緩存

為什么在查找過程中要再做一次緩存呢?

是因為根據異常類型獲取處理方法的時候，一個異常可能有多個處理方法，即一個異常會從mappedMethods中查出多個處理方法，最后返回的是繼承關系最近的異常對應的處理方法，所以在查找的時候又做了一次緩存，避免每次查mappedMethods然后取最優值。從exceptionLookupCache中就可以直接查到最優的處理方法

以LocationController為例，查找一次異常后，exceptionLookupCache的值如下

這樣當再次發生ArithmeticException異常時就能從exceptionLookupCache找到對應的處理方法

ResponseStatusExceptionResolver

ResponseStatusExceptionResolver和DefaultHandlerExceptionResolver的實現都不是很難，就不進行過多的分析了

ResponseStatusExceptionResolver主要用來處理如下異常

拋出的異常類型繼承自ResponseStatusException

拋出的異常類型被@ResponseStatus標記

以一個例子來演示這個處理器的功能

  1. @ResponseStatus(HttpStatus.UNAUTHORIZED) 
  2. public class UnauthorizedException extends RuntimeException { 
  3. } 
  4. @RestController 
  5. @RequestMapping("shoppingCar") 
  6. public class ShoppingCarController { 
  7.  
  8.  @RequestMapping("getCarInfo") 
  9.  public String index() { 
  10.   throw new UnauthorizedException(); 
  11.  } 
  12. } 

訪問

  1. http://localhost:8080/shoppingCar/getCarInfo 

顯示如下

DefaultHandlerExceptionResolver

用來處理一些常見的Http異常，如

400：請求無效 405：請求方法不支持 500：內部服務器錯誤

執行入口

  1. # DispatcherServlet#processDispatchResult的部分方法 
  2. // 處理過程發生了異常 
  3. if (exception != null) { 
  4.  if (exception instanceof ModelAndViewDefiningException) { 
  5.   logger.debug("ModelAndViewDefiningException encountered", exception); 
  6.   // 直接使用異常中封裝的ModelAndView作為最終的ModelAndView結果 
  7.   mv = ((ModelAndViewDefiningException) exception).getModelAndView(); 
  8.  } 
  9.  else { 
  10.   // 其他異常類型，先獲取解析器 
  11.   Object handler = (mappedHandler != null ? mappedHandler.getHandler() : null); 
  12.   // 通過異常解析器將異常解析為一個錯誤視圖 
  13.   mv = processHandlerException(request, response, handler, exception); 
  14.   errorView = (mv != null); 
  15.  } 
  16. } 

如果整個處理過程發生異常，依次調用DispatcherServlet的成員變量handlerExceptionResolvers的resolveException方法，找到第一個不為null的ModelAndView，然后返回

  1. @Nullable 
  2. private List<HandlerExceptionResolver> handlerExceptionResolvers; 

本文轉載自微信公眾號「Java識堂」，可以通過以下二維碼關注。轉載本文請聯系Java識堂公眾號。

 

責任編輯：武曉燕 來源： Java識堂
異常解析器Spring MVC
相關推薦

2017-11-28 15:29:04

iPhone X網頁適配

2021-05-24 10:50:10

Git命令Linux

2012-01-09 16:28:01

筆記本評測

2009-12-14 18:59:27

Ruby解析器

2020-06-16 10:57:20

搭建

2024-08-28 08:42:21

API接口限流

2016-07-22 15:12:12

Win10技巧重裝

2020-09-24 10:26:43

運維開發技術

2021-02-26 10:21:35

比特幣投資金融

2020-04-20 10:47:57

Redis數據開發

2023-08-26 21:42:08

零拷貝I/O操作

2021-12-27 07:31:37

JavaNeo4J數據庫

2023-02-23 08:15:33

Spring異常處理機制

2023-07-27 08:26:36

零拷貝I/O操作

2019-05-13 08:24:58

數據庫MySQLInnoDB

2021-10-28 19:23:27

界面嵌入式 UI

2024-02-27 08:14:51

Nginx跨域服務

2009-03-19 09:26:05

RSS解析器MagpieRSS

2023-07-10 08:00:13

架構Rest返回值

2011-05-24 09:22:44

Spring3異常處理
點贊
收藏

51CTO技術棧公眾號

主站蜘蛛池模板： 色综合久久天天综合网 | 亚洲午夜精品一区二区三区他趣 | 伊人二区| 亚洲三级在线观看 | 成人午夜免费视频 | 最新av在线网址 | 日韩av在线一区二区 | 在线视频一区二区 | 日韩在线电影 | 国产99久久精品一区二区永久免费 | 99久久99| 91精品国产欧美一区二区 | 日本精品久久久久 | 日韩免费视频一区二区 | 99久热| 国产美女视频一区 | 亚洲天堂网站 | 亚洲三级视频 | 欧美在线一区二区三区 | 黄色国产在线播放 | 综合激情网 | 精品久久久久香蕉网 | 国产精品免费一区二区三区四区 | 国产超碰人人爽人人做人人爱 | 欧美精品被 | 国产精品1区 | 99久久婷婷国产综合精品电影 | www.中文字幕.com | 日韩一级欧美一级 | 久久久久成人精品免费播放动漫 | 国产伦精品一区二区三区照片91 | 日本超碰| 欧美性受xxxx白人性爽 | 亚洲国产精品区 | 亚洲精品福利在线 | 九九亚洲精品 | 久久久久久精 | 国产伦精品一区二区三区照片91 | 国产伊人久久久 | 国产精品国产精品国产专区不卡 | 亚洲久在线|