2. 程式人生 > >SpringMVC原始碼剖析（七）- HandlerExceptionResolver異常解析器家族揭祕

SpringMVC原始碼剖析（七）- HandlerExceptionResolver異常解析器家族揭祕

阿新 • • 發佈：2019-01-09

在Spring MVC中，所有用於處理在請求處理過程中丟擲的異常，都要實現HandlerExceptionResolver介面。HandlerExceptionResolver是Spring MVC提供的非常好的通用異常處理工具，不過需要注意的是，它只能處理請求過程中丟擲的異常，異常處理本身所丟擲的異常和檢視解析過程中丟擲的異常它是不能處理的。AbstractHandlerExceptionResolver實現該介面和Orderd介面，是HandlerExceptionResolver類的實現的基類。ResponseStatusExceptionResolver等具體的異常處理類均在AbstractHandlerExceptionResolver之上，實現了具體的異常處理方式。一個基於Spring MVC的Web應用程式中，可以存在多個實現了HandlerExceptionResolver的異常處理類，他們的執行順序，由其order屬性決定, order值越小，越是優先執行, 在執行到第一個返回不是null的ModelAndView的Resolver時，不再執行後續的尚未執行的Resolver的異常處理方法。

<mvc:annotation-driven/>會自動將ExceptionHandlerExceptionResolver, ResponseStatusExceptionResolver, DefaultHandlerExceptionResolver配置到Spring MVC中，並且其中ExceptionHandlerExceptionResolver優先順序最高，ResponseStatusExceptionResolver第二，DefaultHandlerExceptionResolver第三。如果你想使用SimpleMappingExceptionResolver，你需要自己將SimpleMappingExceptionResolver配置到Spring MVC中。另外ExceptionHandlerExceptionResolver不僅可以解析處理器類中註解的@

ExceptionHandler的方法，還可以使用@ControllerAdvice註解的類裡的有@ExceptionHandler註解的全域性異常處理方法。

我們首先看一下HandlerExceptionResolver家族體系的結構：


其中HandlerExceptionResolverComposite作為容器使用，可以封裝別的Resolver，它並不會解析具體的異常，而是呼叫其他的異常解析器處理異常。這裡我們不需要去研究它。

而AnnotationMethodHandlerExceptionResolver已經被棄用了，所以不需要解析。剩下的是我們研究的重點：

1. AbstractHandlerMethodExceptionResolver和ExceptionHandlerExceptionResolver一起使用，完成使用@ExceptionHandler註釋的方法進行對異常的解析。

2. ResponseStatusExceptionResolver: 解析有@ResponseStatus註解的異常。

3. DefaultHandlerExceptionResolver：按照不同的型別分別對異常進行解析。

4. SimpleMappingExceptionResolver: 通過配置的異常類和view的對應關係來解析異常。

下面我們具體的分析這些異常解析器。

首先我們HandlerExceptionResolver介面的原始碼，我去掉了原始碼中不關心的註釋的部分：

public interface HandlerExceptionResolver {

	ModelAndView resolveException(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex);
Spring MVC的異常處理只是處理請求處理過程中異常，既然是"請求處理過程中"的異常，我們必然會知道本次請求的handler物件，以及被丟擲的Exception物件，既然是本次請求，肯定還會出現與請求有關的request和response物件。這就很好的說明了為什麼resolveException方法中會出現這四個引數。

為什麼我一直都說Spring MVC的異常處理體系只是處理請求處理過程的異常呢？我們來分析下原始碼，下面的原始碼出自DispatcherServlet的doDispatch方法，我省略了部分不重要的內容：

protected void doDispatch(HttpServletRequest request, HttpServletResponse response) throws Exception {
		try {
			//請求處理的程式碼
			}
			catch (Exception ex) {
				dispatchException = ex;
			}
			processDispatchResult(processedRequest, response, mappedHandler, mv, dispatchException);
		}
		finally {

		}
	}
在請求處理過程中發生的異常，都會進入到processDispatchResult方法中，我去掉了不關心的部分： 
private void processDispatchResult(HttpServletRequest request, HttpServletResponse response,
			HandlerExecutionChain mappedHandler, ModelAndView mv, Exception exception) throws Exception {
		if (exception != null) {
			if (exception instanceof ModelAndViewDefiningException) {
				logger.debug("ModelAndViewDefiningException encountered", exception);
				mv = ((ModelAndViewDefiningException) exception).getModelAndView();
			}
			else {
				Object handler = (mappedHandler != null ? mappedHandler.getHandler() : null);
				mv = processHandlerException(request, response, handler, exception);
				errorView = (mv != null);
			}
		}
	}
會發現在這個方法實際呼叫的是processHandlerException方法，我去掉了不關心的部分： 
protected ModelAndView processHandlerException(HttpServletRequest request, HttpServletResponse response,
			Object handler, Exception ex) throws Exception {
		ModelAndView exMv = null;
		for (HandlerExceptionResolver handlerExceptionResolver : this.handlerExceptionResolvers) {
			exMv = handlerExceptionResolver.resolveException(request, response, handler, ex);
			if (exMv != null) {
				break;
			}
		}
		throw ex;
	}
會發現這個方法遍歷了handlerExceptionResolvers異常解析器列表，這個handlerExceptionResolvers異常解析器列表是DispatcherServlet初始化的時候建立的。通常handlerExceptionResolvers異常解析器列表裡面包含了上面我們所講述的ExceptionHandlerExceptionResolver和ResponseStatusExceptionResolver以及DefaultHandlerExceptionResolver。

HandlerExceptionResolver異常體系中使用到模板設計模式，HandlerExceptionResolver介面定義了處理異常的標準API，而AbstractHandlerExceptionResolver則定義了處理異常的步驟。下面是AbstractHandlerExceptionResolver原始碼：

public ModelAndView resolveException(HttpServletRequest request, HttpServletResponse response,
			Object handler, Exception ex) {

		if (shouldApplyTo(request, handler)) {
			// Log exception, both at debug log level and at warn level, if desired.
			if (logger.isDebugEnabled()) {
				logger.debug("Resolving exception from handler [" + handler + "]: " + ex);
			}
			logException(ex, request);
			prepareResponse(ex, response);
			return doResolveException(request, response, handler, ex);
		}
		else {
			return null;
		}
	}
第一步：判斷當前所用的異常處理器是否可以處理當前的handler。如果不可以，就返回null, 這樣在DispatcherServlet裡面就會繼續遍歷handlerExceptionResolvers異常解析器列表，尋找下一個異常解析器來處理當前的handler。如果可以，就繼續進行下面的第二步。那麼它是如何判斷的呢？我們來研究下shouldApplyTo方法： 
protected boolean shouldApplyTo(HttpServletRequest request, Object handler) {
		if (handler != null) {
			if (this.mappedHandlers != null && this.mappedHandlers.contains(handler)) {
				return true;
			}
			if (this.mappedHandlerClasses != null) {
				for (Class<?> handlerClass : this.mappedHandlerClasses) {
					if (handlerClass.isInstance(handler)) {
						return true;
					}
				}
			}
		}
		// Else only apply if there are no explicit handler mappings.
		return (this.mappedHandlers == null && this.mappedHandlerClasses == null);
	}
this.mappedHandlers代表當前的異常處理器可以處理哪些handler,如果目標handler非空，並且異常處理器可以處理的handler包含目標handler，我們就說這個異常處理器可以處理目標handler的異常。下面的if條件的內容與此相似。

第二步：logException就是將exception打印出來。

第三步：prepareResponse方法根據preventResponseCaching標誌判斷是否給response設定禁用快取的屬性。

第四步：doResolveException方法是模板方法，至於具體的如何處理異常，應該交給具體的異常解析器來進行處理。

ExceptionHandlerExceptionResolver

ExceptionHandlerExceptionResolver的父類AbstractHandlerMethodExceptionResolver重寫了shouldApplyTo方法：

protected boolean shouldApplyTo(HttpServletRequest request, Object handler) {
		if (handler == null) {
			return super.shouldApplyTo(request, handler);
		}
		else if (handler instanceof HandlerMethod) {
			HandlerMethod handlerMethod = (HandlerMethod) handler;
			handler = handlerMethod.getBean();
			return super.shouldApplyTo(request, handler);
		}
		else {
			return false;
		}
	}
在這裡我們可以看出，如果我們的handler為空，就呼叫父類的shouldApplyTo方法，如果handler非空，就判斷handler是否是屬於HandlerMethod型別，如果是就獲取HandlerMethod處理器的型別資訊，賦給當前的handler,然後還是呼叫父類的shouldApplyTo方法進行處理，否則返回false。

AbstractHandlerMethodExceptionResolver的作用就相當於一個介面卡，一般的處理器是類的形式，但是HandlerMethod其實是講方法作為處理器來使用的，所以需要適配。

AbstractHandlerMethodExceptionResolver裡面的doResolveException將處理傳遞給了doResolveHandlerMethodException方法具體處理，而doResolveHandlerMethodException是一個模板方法，由ExceptionHandlerExceptionResolver具體實現。

ResponseStatusExceptionResolver

現在我們看下ResponseStatusExceptionResolver的doResolveException方法：

protected ModelAndView doResolveException(HttpServletRequest request, HttpServletResponse response,
			Object handler, Exception ex) {

		ResponseStatus responseStatus = AnnotationUtils.findAnnotation(ex.getClass(), ResponseStatus.class);
		if (responseStatus != null) {
			try {
				return resolveResponseStatus(responseStatus, request, response, handler, ex);
			}
			catch (Exception resolveEx) {
				logger.warn("Handling of @ResponseStatus resulted in Exception", resolveEx);
			}
		}
		return null;
	}
首先獲取當前的exception是否存在@ResponseStatus註解，如果存在,就使用resolveResponseStatus方法處理. 
protected ModelAndView resolveResponseStatus(ResponseStatus responseStatus, HttpServletRequest request,
			HttpServletResponse response, Object handler, Exception ex) throws Exception {

		int statusCode = responseStatus.value().value();
		String reason = responseStatus.reason();
		if (this.messageSource != null) {
			reason = this.messageSource.getMessage(reason, null, reason, LocaleContextHolder.getLocale());
		}
		if (!StringUtils.hasLength(reason)) {
			response.sendError(statusCode);
		}
		else {
			response.sendError(statusCode, reason);
		}
		return new ModelAndView();
	}
獲取@ResponseStatus註解中的value和reason的值，然後設定到當前的response中去。

DefaultHandlerExceptionResolver

DefaultHandlerExceptionResolver是根據異常的具體型別來進行處理：

protected ModelAndView doResolveException(HttpServletRequest request, HttpServletResponse response,
			Object handler, Exception ex) {

		try {
			if (ex instanceof NoSuchRequestHandlingMethodException) {
				return handleNoSuchRequestHandlingMethod((NoSuchRequestHandlingMethodException) ex, request, response,
						handler);
			}
			else if (ex instanceof HttpRequestMethodNotSupportedException) {
				return handleHttpRequestMethodNotSupported((HttpRequestMethodNotSupportedException) ex, request,
						response, handler);
			}
			else if (ex instanceof HttpMediaTypeNotSupportedException) {
				return handleHttpMediaTypeNotSupported((HttpMediaTypeNotSupportedException) ex, request, response,
						handler);
			}
			else if (ex instanceof HttpMediaTypeNotAcceptableException) {
				return handleHttpMediaTypeNotAcceptable((HttpMediaTypeNotAcceptableException) ex, request, response,
						handler);
			}
			else if (ex instanceof MissingServletRequestParameterException) {
				return handleMissingServletRequestParameter((MissingServletRequestParameterException) ex, request,
						response, handler);
			}
			else if (ex instanceof ServletRequestBindingException) {
				return handleServletRequestBindingException((ServletRequestBindingException) ex, request, response,
						handler);
			}
			else if (ex instanceof ConversionNotSupportedException) {
				return handleConversionNotSupported((ConversionNotSupportedException) ex, request, response, handler);
			}
			else if (ex instanceof TypeMismatchException) {
				return handleTypeMismatch((TypeMismatchException) ex, request, response, handler);
			}
			else if (ex instanceof HttpMessageNotReadableException) {
				return handleHttpMessageNotReadable((HttpMessageNotReadableException) ex, request, response, handler);
			}
			else if (ex instanceof HttpMessageNotWritableException) {
				return handleHttpMessageNotWritable((HttpMessageNotWritableException) ex, request, response, handler);
			}
			else if (ex instanceof MethodArgumentNotValidException) {
				return handleMethodArgumentNotValidException((MethodArgumentNotValidException) ex, request, response, handler);
			}
			else if (ex instanceof MissingServletRequestPartException) {
				return handleMissingServletRequestPartException((MissingServletRequestPartException) ex, request, response, handler);
			}
			else if (ex instanceof BindException) {
				return handleBindException((BindException) ex, request, response, handler);
			}
			else if (ex instanceof NoHandlerFoundException) {
				return handleNoHandlerFoundException((NoHandlerFoundException) ex, request, response, handler);
			}
		}
		catch (Exception handlerException) {
			logger.warn("Handling of [" + ex.getClass().getName() + "] resulted in Exception", handlerException);
		}
		return null;
	}

各種異常解析器的使用

在我們自定義的異常上使用ResponseStatus註解。當我們的Controller丟擲異常，並且沒有被處理的時候，他將返回HTTP STATUS 為指定值的 HTTP RESPONSE，比如：

@ResponseStatus(value=HttpStatus.NOT_FOUND, reason="No such Order")  // 404
    public class OrderNotFoundException extends RuntimeException {
        // ...
    }

我們的Controller為：

 @RequestMapping(value="/orders/{id}", method=GET)
    public String showOrder(@PathVariable("id") long id, Model model) {
        Order order = orderRepository.findOrderById(id);
        if (order == null) throw new OrderNotFoundException(id);
        model.addAttribute(order);
        return "orderDetail";
    }
這時候會返回404，轉到404頁面而不是錯誤頁面。
  1. 發生異常後，改變Response status，一般而言，發生異常返回HTTP STATUS 500.我們可以變為其他。
  2. 發生錯誤後轉到錯誤頁面
  3. 可以為不同異常定義不同處理（如不同的錯誤頁面，不同的Response status）

舉例說明：

@Controller
public class ExceptionHandlingController {

  // 我們標註了@RequestMapping的方法
  ...
  
  //處理異常的方法。
  
  // 把我們定義的異常轉換為特定的Http status code
  @ResponseStatus(value=HttpStatus.CONFLICT, reason="Data integrity violation")  // 409
  @ExceptionHandler(DataIntegrityViolationException.class)
  public void conflict() {
    // Nothing to do
  }
  

  // 捕獲到SQLException，DataAccessException異常之後，轉到特定的頁面。
  @ExceptionHandler({SQLException.class,DataAccessException.class})
  public String databaseError() {
    //僅僅轉到錯誤頁面，我們在頁面上得不到這個Exception的值，要得到值，我們可以通過下面的方法得到
    return "databaseError";
  }

  // 通過ModelAndView返回頁面，以及往頁面傳相應的值
  @ExceptionHandler(Exception.class)
  public ModelAndView handleError(HttpServletRequest req, Exception exception) {
    logger.error("Request: " + req.getRequestURL() + " raised " + exception);

    ModelAndView mav = new ModelAndView();
    mav.addObject("exception", exception);
    mav.addObject("url", req.getRequestURL());
    mav.setViewName("error");
    return mav;
  }
}


class GlobalControllerExceptionHandler {
    @ResponseStatus(HttpStatus.CONFLICT)  // 409
    @ExceptionHandler(DataIntegrityViolationException.class)
    public void handleConflict() {
        // Nothing to do
    }
    
   //轉到特定頁面 。。。。。
}

如果我們要處理程式中所有的異常可以這麼做：
@ControllerAdvice
class GlobalDefaultExceptionHandler {
    public static final String DEFAULT_ERROR_VIEW = "error";

    @ExceptionHandler(value = Exception.class)
    public ModelAndView defaultErrorHandler(HttpServletRequest req, Exception e) throws Exception {
        // If the exception is annotated with @ResponseStatus rethrow it and let
        // the framework handle it - like the OrderNotFoundException example
        // at the start of this post.
        // AnnotationUtils is a Spring Framework utility class.
        if (AnnotationUtils.findAnnotation(e.getClass(), ResponseStatus.class) != null) {
            throw e;
        }
        // Otherwise setup and send the user to a default error-view.
        ModelAndView mav = new ModelAndView();
        mav.addObject("exception", e);
        mav.addObject("url", req.getRequestURL());
        mav.setViewName(DEFAULT_ERROR_VIEW);
        return mav;
    }
}


參考文獻：

相關推薦

SpringMVC原始碼剖析（七）- HandlerExceptionResolver異常解析器家族揭祕

在Spring MVC中，所有用於處理在請求處理過程中丟擲的異常，都要實現HandlerExceptionResolver介面。HandlerExceptionResolver是Spring MVC提供的非常好的通用異常處理工具，不過需要注意的是，它只能處理請求過程中丟擲的

Redis原始碼剖析（七）--壓縮列表

壓縮列表的構成 壓縮列表是為了節省記憶體而開發的，可以包含任意多個節點(entry)，每一個節點可以儲存一個位元組陣列或者一個整數值。 下圖展示了壓縮列表的各個組成部分， zlbytes：4位元組，壓縮列表所用的位元組數 zltail：4位元組，記錄壓縮列表尾節點entryN距離壓縮列表的

SpringMVC原始碼剖析（一）- 從抽象和介面說起

註明：文章是本人在中國開源網上看到的經典文章，出處：http://my.oschina.net/lichhao 作者：相見歡 SpringMVC作為Struts2之後異軍突起的一個表現層框架，正越來越流行，相信javaee的開發者們就算沒使用過Sprin

SpringMVC原始碼剖析（一）SpringMVC整體架構分析和建立

先看一下Servlet的繼承結 前面的Servlet體系我都有講過HttpServlet實現了根據動作分發請求 其他結構重要的類為HttpServletBean，FrameworkServlet ,DispatcherServlet 在Spring中實現了XXXAware

SpringMVC原始碼剖析（二）- DispatcherServlet的前世今生

上一篇文章《SpringMVC原始碼剖析（一）- 從抽象和介面說起》中，我介紹了一次典型的SpringMVC請求處理過程中，相繼粉墨登場的各種核心類和介面。我刻意忽略了原始碼中的處理細節，只列出最簡單的類甚至是介面類，目的就是讓大家先從最高層次的抽象意義上來審視Spr

Linux進程間通信的幾種方式總結--linux內核剖析（七）

字節流 標準 包含 down pro trac posix共享內存 ++ 實現 進程間通信概述 進程通信的目的 傳輸數據 一個進程須要將它的數據發送給還有一個進程。發送的數據量在一個字節到幾M字節之間 共享數據 多個進程想要操作共享

Flume NG原始碼分析（七）ChannelSelector

前幾篇介紹了Flume NG Source元件的基本情況，接下來看看Channel相關的元件，Channel相關元件有： 1. Channel 2. ChannelSelector 3. Interceptor / InterceptorChain 4. ChannelProcess

Zookeeper原始碼閱讀（七） Server端Watcher

前言 前面一篇主要介紹了Watcher介面相關的介面和實體類，但是主要是zk客戶端相關的程式碼，如前一篇開頭所說，client需要把watcher註冊到server端，這一篇分析下server端的watcher。 主要分析Watchmanager類。 Watchmanager 這是WatchMan

STL原始碼剖析（三）迭代器與traits程式設計

文章目錄 1. 迭代器概念 1.1 基本概念 1.2 迭代器設計理念 2. 引出traits程式設計 3. traits程式設計 3.1 traits程式設計技術 3.2 partial special

STL原始碼剖析（二）空間配置器

歡迎大家來訪二笙的小房子，一同學習分享生活！ 文章目錄 1. 寫在前面 2. SGI空間配置器 2.1 SGI標準空間配置器 2.2 SGI特殊的空間配置器，std::alloc 2.3 構造和析構基本工具 2.4 空間

STL原始碼剖析（五）【hash_set、hash_map】

hash_set 與set區別及聯絡 與set大同小異，set以RB-tree作為其底層，而hash_set以hash table作為其底層 兩者都是藉由其底層操作完成我們所看到的那些操作 二者最大的不同在於set的底層RB-tree有自動排序功能，所以反映在se

STL原始碼剖析（五）hashtable

文章目錄 1. hashtable概述 1.1 線性探測 1.2 二次探測 1.3 開鏈法 2. hashtable的桶與節點 3. hashtable迭代器 4. hashtable資料結構 5. has

STL原始碼剖析（五）關聯式容器--【set、multiset、map、multimap】

文章目錄 1. 寫在前面 2. set 2.1 set性質 2.2 set實現 2.3 multiset 3. map 3.1 map性質 3.2 pair 3.3 map實現

STL原始碼剖析（四）序列式容器--slist

文章目錄 1. slist概述 2. slist的節點及迭代器 2.1節點設計： 2.2 迭代器設計： 3. 資料結構 4. 元素操作 1. slist概述 slist，即我們資料結構課程中

STL原始碼剖析（四）heap--priority_queue

文章目錄 1. heap概述 2. 為何選擇heap作為priority queue的底層機制？ 3. binary heap 4. heap演算法 5. priority_queue 1. heap概述 heap,

STL原始碼剖析（四）容器介面卡--stack、queue

文章目錄 1. 寫在前面 2. stack--queue 2.1 satck概述 2.1.1 stack實現 2.1.2 stack迭代器 2.2 queue概述 2.2.1 qu

STL原始碼剖析（四）序列式容器--deque

文章目錄 1. 關於deque 1.1 deque概述 1.2 deque與vector區別 2. deque構成 3. deque的迭代器 4. deque構造與記憶體管理 4.1 deque構造

STL原始碼剖析（四）序列式容器--list

文章目錄 1. 關於list 1.1 首先在介紹list之前先來觀察一下list的節點結構： 1.2 與vector的區別 2. list的迭代器 3. list的資料結構 4. list記憶體構造 5. list

Redis原始碼剖析（二）--簡單動態字串

 Redis沒有使用C語言的字串結構，而是自己設計了一個簡單的動態字串結構sds。它的特點是：可動態擴充套件記憶體、二進位制安全和與傳統的C語言字串型別相容。下面就從原始碼的角度來分析一下Redis中sds的實現。   1 SDS的定義 // sds相容傳統C風格字串，所以起了

SpringMVC的學習（七）——RESTful風格

一、RESTful介紹 REST:即Representational State Transfer , (資源)表現層狀態轉化,是目前最流行的一種網際網路軟體架構。它結構清晰、符合標註、易於理解、方便擴充套件，所以越來越多的網站採用！ 具體說，就是HTTP協議裡面,四個表示操作方式的動詞: