程序員筆記|常見的Spring異常處理

一、前言

相信我們每個(gè)人在SpringMVC開發(fā)中,都遇到這樣的問題:當(dāng)我們的代碼正常運(yùn)行時(shí),返回的數(shù)據(jù)是我們預(yù)期格式,比如json或xml形式,但是一旦出現(xiàn)了異常(比如:NPE或者數(shù)組越界等等),返回的內(nèi)容確實(shí)服務(wù)端的異常堆棧信息,從而導(dǎo)致返回的數(shù)據(jù)不能使客戶端正常解析; 很顯然,這些并不是我們希望的結(jié)果。

創(chuàng)新互聯(lián)-云計(jì)算及IDC服務(wù)提供商,涵蓋公有云、IDC機(jī)房租用、成都服務(wù)器托管、等保安全、私有云建設(shè)等企業(yè)級互聯(lián)網(wǎng)基礎(chǔ)服務(wù),溝通電話:028-86922220

我們知道,一個(gè)較為常見的系統(tǒng),會涉及控制層,服務(wù)(業(yè)務(wù))層、緩存層、存儲層以及接口調(diào)用等,其中每一個(gè)環(huán)節(jié)都不可避免的會遇到各種不可預(yù)知的異常需要處理。如果每個(gè)步驟都單獨(dú)try..catch會使系統(tǒng)顯的很雜亂,可讀性差,維護(hù)成本高;常見的方式就是,實(shí)現(xiàn)統(tǒng)一的異常處理,從而將各類異常從各個(gè)模塊中解耦出來;

二、常見全局異常處理

在Spring中常見的全局異常處理,主要有三種:

(1)注解ExceptionHandler

(2)繼承HandlerExceptionResolver接口

(3)注解ControllerAdvice

在后面的講解中,主要以HTTP錯誤碼:400(請求無效)和500(內(nèi)部服務(wù)器錯誤)為例,先看一下測試代碼以及沒有任何處理的返回結(jié)果,如下:

程序員筆記|常見的Spring異常處理

(圖1:測試代碼)

程序員筆記|常見的Spring異常處理

(圖2:沒有異常的錯誤返回)

2.1 注解ExceptionHandler

注解ExceptionHandler作用對象為方法,最簡單的使用方法就是放在controller文件中,詳細(xì)的注解定義不再介紹。如果項(xiàng)目中有多個(gè)controller文件,通常可以在baseController中實(shí)現(xiàn)ExceptionHandler的異常處理,而各個(gè)contoller繼承basecontroller從而達(dá)到統(tǒng)一異常處理的目的。因?yàn)楸容^常見,簡單代碼如下:

程序員筆記|常見的Spring異常處理

(圖3:Controller中的ExceptionHandler使用)

在返回異常時(shí),添加了所屬的類名,便于大家記憶理解。運(yùn)行看一下結(jié)果:

程序員筆記|常見的Spring異常處理

(圖4:添加ExceptionHandler之后的結(jié)果)

  • 優(yōu)點(diǎn):ExceptionHandler簡單易懂,并且對于異常處理沒有限定方法格式;

  • 缺點(diǎn):由于ExceptionHandler僅作用于方法,對于多個(gè)controller的情況,僅為了一個(gè)方法,所有需要異常處理的controller都繼承這個(gè)類,明明不相關(guān)的東西,強(qiáng)行給他們找個(gè)爹,不太好。

2.2 注解ControllerAdvice

這里雖說是ControllerAdvice注解,其實(shí)是其與ExceptionHandler的組合使用。在上文中可以看到,單獨(dú)使用@ExceptionHandler時(shí),其必須在一個(gè)Controller中,然而當(dāng)其與ControllerAdvice組合使用時(shí)就完全沒有了這個(gè)限制。換句話說,二者的組合達(dá)到的全局的異常捕獲處理。

程序員筆記|常見的Spring異常處理

(圖5:注解ControllerAdvice異常處理代碼)

在運(yùn)行之前,需將之前Controller中的ExceptionHandler注釋掉,測試結(jié)果如下:

程序員筆記|常見的Spring異常處理

(圖6:注解ControllerAdvice異常處理結(jié)果)

通過上面結(jié)果可以看到,異常處理確實(shí)已經(jīng)變更為ExceptionHandlerAdvice類。這種方法將所有的異常處理整合到一處,去除了Controller中的繼承關(guān)系,并且達(dá)到了全局捕獲的效果,推薦使用此類方式;

2.3 實(shí)現(xiàn)HandlerExceptionResolver接口

HandlerExceptionResolver本身SpringMVC內(nèi)部的接口,其內(nèi)部只有resolveException一個(gè)方法,通過實(shí)現(xiàn)該接口我們可以達(dá)到全局異常處理的目的。

程序員筆記|常見的Spring異常處理

(圖7:實(shí)現(xiàn)HandlerExceptionResolver接口)

同樣在執(zhí)行之前,將上述兩個(gè)方法的異常處理都注釋掉,運(yùn)行結(jié)果如下:

程序員筆記|常見的Spring異常處理

(圖8:實(shí)現(xiàn)HandlerExceptionResolver接口運(yùn)行結(jié)果)

可以看到500的異常處理已經(jīng)生效了,但是400的異常處理卻沒有生效,并且根沒有異常前的返回結(jié)果一樣。這是怎么回事呢?不是說可以做到全局異常處理的么?沒辦法要想知道問題的原因,我們只能刨根問底,往Spring的祖墳上刨,下面我們結(jié)合Spring的源碼調(diào)試,去需要原因。

三、Spring中異常處理源碼分析

大家都知道,在Spring中第一個(gè)收到請求的類就是DispatcherServlet,而該類中核心的方法就是doDispatch,我們可以在該類中打斷點(diǎn),進(jìn)而一步步跟進(jìn)異常處理。

3.1 HandlerExceptionResolver實(shí)現(xiàn)類處理流程

參照如下的跟進(jìn)步驟,在processHandlerException中斷點(diǎn),跟蹤的結(jié)果如下圖:

程序員筆記|常見的Spring異常處理

程序員筆記|常見的Spring異常處理

(圖9:processHandlerException斷點(diǎn))

可以看到在圖中箭頭【1】處,在遍歷 handlerExceptionResolvers 進(jìn)而來處理異常,而在箭頭【2】處,看到handlerExceptionResolvers 中共有4個(gè)元素,其中最后一個(gè)就是2.3方法定義的異常處理類

當(dāng)前的請求query請求,根據(jù)上述現(xiàn)象可以推測出,該異常處理應(yīng)該是在前3個(gè)異常處理中被處理了,從而跳過我們自定義的異常;帶著這樣的猜測,我們F8繼續(xù)跟進(jìn),可以跟蹤到該異常是被第三個(gè),即DefaultHandlerExceptionResolver所處理。

  • DefaultHandlerExceptionResolver:SpringMVC默認(rèn)裝配了DefaultHandlerExceptionResolver,該類的doResolveException方法中主要對一些特殊的異常進(jìn)行處理,并將這類異常轉(zhuǎn)換為相應(yīng)的響應(yīng)狀態(tài)碼。而query請求觸發(fā)的異常為MissingServletRequestParameterException,其恰好也是被DefaultHandlerExceptionResolver所針對的異常,故會在該類中被異常捕獲。

到此真相大白了,可以看到我們的自定義類MyHandlerExceptionResolver確實(shí)可以做到全局處理異常,只不過對于query請求的異常,中間被DefaultHandlerExceptionResolver插了一腳,所以就跳過了MyHandlerExceptionResolver類的處理,從而出現(xiàn)400的返回結(jié)果。而對于calc請求,中間沒有阻攔,所以就達(dá)到了預(yù)期效果。

3.2 三類異常的處理順序

到此我們一共介紹了3類全局異常處理,按照上面的分析可以看出,實(shí)現(xiàn)HandlerExceptionResolver接口的方式是排在最后處理,那么@ExceptionHandler和@ControllerAdvice這兩個(gè)的順序誰先誰后呢? 將三類異常處理全部打開(之前注釋掉了),運(yùn)行一下看看效果:

程序員筆記|常見的Spring異常處理

(圖10:異常處理全放開運(yùn)行結(jié)果)

通過現(xiàn)象可以看到,Controller中單獨(dú)@ExceptionHandle異常處理排在了首位,@ControllerAdvice排在了第二位。嚴(yán)謹(jǐn)?shù)耐梢詫憘€(gè)Controller02,將query和calc復(fù)制過去,異常處理就不要了,這樣請求c02的方法時(shí),異常捕獲的所屬類名就都是@ControllerAdvice所在類了。

以上都是我們根據(jù)現(xiàn)象得到的結(jié)論,下面去Spring源碼去找“證據(jù)”。在圖9中,handlerExceptionResolvers中有4類處理器,而@ExceptionHandler和@ControllerAdvice的處理就在第一個(gè)ExceptionHandlerExceptionResolver中(之前斷點(diǎn)跟進(jìn)即可獲知)。繼續(xù)跟進(jìn)直到進(jìn)入ExceptionHandlerExceptionResolver類的doResolveHandlerMethodException方法,這里的HandlerMethod就是Spring將HTTP請求映射到指定Controller中的方法,而Exception就是需要被捕獲的異常;繼續(xù)跟進(jìn),看看使用這兩個(gè)參數(shù)到底干了什么事兒。

程序員筆記|常見的Spring異常處理

(圖11:doResolveHandlerMethodException斷點(diǎn))

繼續(xù)跟進(jìn)getExceptionHandlerMethod方法,發(fā)現(xiàn)有兩個(gè)變量可能就是問題的關(guān)鍵:exceptionHandlerCache和exceptionHandlerAdviceCache。首先,兩者的變量名很值得懷疑;其次,前者在代碼中看,明顯是通過類作為key,從而得到一個(gè)處理器(resolver),這恰好Controller中@ExceptionHandler處理規(guī)則相吻合;最后,這兩個(gè)Cache的處理順序,也符合之前的得到的結(jié)論。正如之前猜測的那樣,Spring中確實(shí)是優(yōu)先根據(jù)Controller類名去查找對應(yīng)的ExceptionHandler,沒有找到的話,再進(jìn)行@ControllerAdvice異常處理。

程序員筆記|常見的Spring異常處理

(圖12:兩個(gè)異常處理Cache )

如有興趣可繼續(xù)深入挖掘Spring的源碼,這里針對 ExceptionHandlerExceptionResolver 簡單做個(gè)總結(jié):

  • exceptionHandlerCache中包含Controller中的ExceptionHandler異常處理,處理時(shí)通過HandlerMethod得到Controller,進(jìn)而再找到異常處理方法,需要注意的是,其是在異常處理過程中put值的;

  • exceptionHandlerAdviceCache則是在項(xiàng)目啟動時(shí)初始化的,大概思路是找到帶有@ControllerAdvice注解的bean,從而緩存bean中的ExceptionHandler,在異常處理時(shí)需要對齊遍歷查找處理,進(jìn)而達(dá)到全局處理的目的。

3.3 咸魚翻身

介紹了這么多,簡單畫張圖總結(jié)一下。藍(lán)色的部分是Spring默認(rèn)添加的3類異常處理器,×××部分是我們添加的異常處理以及其所被調(diào)用的位置和順序??纯茨睦镞€有不太清楚的,往回翻翻看(ResponseStatusExceptionResolver是針對@ResponseStatus注解,這里不再詳述)。

程序員筆記|常見的Spring異常處理

(圖13:異??偨Y(jié))

如果有需要將MyHandlerExceptionResolver提前處理,甚至排在ExceptionHandlerExceptionResolver之前,能做到么?答案是肯定的,在Spring中如果想將MyHandlerExceptionResolver異常處理提前,需要再實(shí)現(xiàn)一個(gè)Ordered接口,實(shí)現(xiàn)里面的getOrder方法即可,這里返回-1,將其放在最上面,這次咸魚終于可以翻身了。

程序員筆記|常見的Spring異常處理

(圖14:實(shí)現(xiàn)Ordered接口)

運(yùn)行看一下結(jié)果是不是符合預(yù)期,提醒一下,我們?nèi)齻€(gè)異常處理都是生效的,如下圖:

程序員筆記|常見的Spring異常處理

(圖15:實(shí)現(xiàn)Ordered接口運(yùn)行結(jié)果)

四、總結(jié)

本文主要通過介紹SpringMVC中三類常見的全局異常處理,在調(diào)試中發(fā)現(xiàn)了問題,進(jìn)而引發(fā)去Spring源碼中去探究原因,最終解決問題,希望大家能有所收獲。當(dāng)然Spring異常處理類不止介紹的這些,有興趣的童鞋請自行探索!

參考鏈接:

[1] http://www.cnblogs.com/fangjian0423/p/springMVC-request-mapping.html

[2]https://blog.csdn.net/mll999888/article/details/77621352

作者:張遠(yuǎn)航
來源:宜信技術(shù)學(xué)院

本文題目:程序員筆記|常見的Spring異常處理
鏈接URL:http://bm7419.com/article30/igojpo.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供手機(jī)網(wǎng)站建設(shè)、品牌網(wǎng)站制作、域名注冊、Google網(wǎng)站制作、網(wǎng)站設(shè)計(jì)公司

廣告

聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請盡快告知,我們將會在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時(shí)需注明來源: 創(chuàng)新互聯(lián)

h5響應(yīng)式網(wǎng)站建設(shè)