本周在看陳杰寫的自定義異常的微信異常時，使用的是自定義異常狀態碼和信息，在出錯時將他拋出，并用@exceptionhandler注解定義一個全局異常處理器，根據異常的內容向前臺發送狀態碼和信息,處理異常的代碼如下圖:
|
1
2
3
4
5
6
7
|
//處理微信登錄的異常 @exceptionhandler(value = wechatloginexception.class) public string wechatloginexceptionhandler(httpservletrequest request, httpservletresponse response, wechatloginexception e){ logger.error("微信登錄異常：---host {} invokes url {} error: {}", request.getremotehost(), request.getrequesturl(), e.getmessage()); response.setstatus(e.getcode()); return e.getmessage(); } |
在這里我看的時候有點疑惑，將狀態碼寫入響應，而信息卻直接返回了，詢問陳杰，前臺果然沒有接受到e.getmessage()的信息,我上網搜索了一下,推薦他使用response.senderror(code, message)這個方法來返回異常的信息,但是這么一試之后卻遭到了奇怪的問題.
莫名的攔截器
項目配置了一個攔截器，專門用來對用戶進行驗證是否登錄的，這個是前提.在使用response.setstatus()方法時，前臺能正確的接受到傳入的狀態碼，而使用response.senderror()時，前臺卻接受到的一直是401用戶未登錄的狀態碼，打了斷點進行調試,分別在攔截器,跑出異常的方法,處理異常的方法打上斷點,測試使用response.setstatus()和response.senderror()方法來查看執行順序,結果讓我感到驚奇:
使用response.setstatus()執行順序:
使用response.senderror()執行順序:
出現了令人驚奇兩點：
1.setstatus()請求時沒有經過攔截器
2.senderror()在異常處理完畢后經過了一次攔截器
查看注冊攔截器配置,解決了第一個問題的疑惑:
|
1
2
3
4
5
6
|
public void addinterceptors(interceptorregistry registry) { // 添加攔截器，去除對登錄的攔截 registry.addinterceptor(authinterceptor) .excludepathpatterns("/user/login") .excludepathpatterns("/user/wechatlogin"); } |
這個異常是用戶登錄時拋出的，在注冊時將登錄路徑給忽略了，因為我們只是攔截未登錄的請求，而請求登錄的請求不應該攔截，這是正確的，但第二點卻怎么也不明白，本應忽略攔截的請求，為什么換了senderror()方法后，卻在異常處理完畢后經過了異常攔截器?
springboot的默認異常處理
對比兩個方法的不同:setstatus()只是改了一下狀態嗎,而senderror()還有請求錯誤的意味，于是猜想是不是請求錯誤才會出現這種情況,將方法直接改為throw new runtimeexception()(沒有處理異常),發現攔截器攔截的請求的url居然是一個/error的url.
這個/error的url并未在項目中定義過任何的控制器中，也從未發起這樣的請求，上網一查詢,原來這是spring boot提供了一個默認的映射：/error，當處理中拋出異常之后，會轉到該請求中處理，并且該請求有一個全局的錯誤頁面用來展示異常內容.
但是我們的攔截器把這個請求攔截了(并且這個請求沒有攜帶正確的cookie)，所以直接就返回了401錯誤,response中也沒有我們定義的狀態碼和信息了.
json還是html
一切真相大白了，但忽然想到如果是瀏覽器發起的請求，服務器錯誤后springboot默認異常處理返回的是html，但是如果像我們前后臺分離的請求，返回就不應該是html而是json的錯誤信息了，這個要怎么區分呢？
使用google插件發送請求，返回的body是這樣的:
而用瀏覽器發起的請求返回的卻是一個html頁面:
|
1
2
3
4
5
6
7
8
9
|
<html><body><h1>whitelabel error page</h1><p>this application has no explicit mapping for /error, so you are seeing this as a fallback.</p><div id='created'>sat apr 13 21:34:34 cst 2019</div><div>there was an unexpected error (type=internal server error, status=500).</div><div>no message available</div></body></html> |
仔細查看兩者發起的請求不同,在瀏覽器發起請求信息requestheader上發現了accept字段:
|
1
|
accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8 |
頓時就明白了,在發送請求時spring-boot根據accept字段來給你返回響應的內容,例如application/json返回json，text/html返回html，真是感嘆spring-boot真是太周全了.
總結
spring-boot好心幫你默認請求異常，但是卻給你帶來了麻煩，感覺還是自己理解的不夠多，學習路還遠著呢。
以上就是本文的全部內容，希望對大家的學習有所幫助，也希望大家多多支持服務器之家。
原文鏈接：https://segmentfault.com/a/1190000018859168
