快捷導(dǎo)航

spring boot 默認(rèn)異常處理的實(shí)現(xiàn)

更新時(shí)間：2019年04月14日 16:15:19 作者：鯨冬香

這篇文章主要介紹了spring boot 默認(rèn)異常處理的實(shí)現(xiàn)，文中通過(guò)示例代碼介紹的非常詳細(xì)，對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，需要的朋友們下面隨著小編來(lái)一起學(xué)習(xí)學(xué)習(xí)吧

本周在看陳杰寫的自定義異常的微信異常時(shí)，使用的是自定義異常狀態(tài)碼和信息，在出錯(cuò)時(shí)將他拋出，并用@ExceptionHandler注解定義一個(gè)全局異常處理器，根據(jù)異常的內(nèi)容向前臺(tái)發(fā)送狀態(tài)碼和信息,處理異常的代碼如下圖:

//處理微信登錄的異常
  @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();
  }

在這里我看的時(shí)候有點(diǎn)疑惑，將狀態(tài)碼寫入響應(yīng)，而信息卻直接返回了，詢問(wèn)陳杰，前臺(tái)果然沒(méi)有接受到e.getMessage()的信息,我上網(wǎng)搜索了一下,推薦他使用response.sendError(code, message)這個(gè)方法來(lái)返回異常的信息,但是這么一試之后卻遭到了奇怪的問(wèn)題.

莫名的攔截器

項(xiàng)目配置了一個(gè)攔截器，專門用來(lái)對(duì)用戶進(jìn)行驗(yàn)證是否登錄的，這個(gè)是前提.在使用response.setStatus()方法時(shí)，前臺(tái)能正確的接受到傳入的狀態(tài)碼，而使用response.sendError()時(shí)，前臺(tái)卻接受到的一直是401用戶未登錄的狀態(tài)碼，打了斷點(diǎn)進(jìn)行調(diào)試,分別在攔截器,跑出異常的方法,處理異常的方法打上斷點(diǎn),測(cè)試使用response.setStatus()和response.sendError()方法來(lái)查看執(zhí)行順序,結(jié)果讓我感到驚奇:

使用response.setStatus()執(zhí)行順序:

使用response.sendError()執(zhí)行順序:

出現(xiàn)了令人驚奇兩點(diǎn)：

1.setStatus()請(qǐng)求時(shí)沒(méi)有經(jīng)過(guò)攔截器
2.sendError()在異常處理完畢后經(jīng)過(guò)了一次攔截器

查看注冊(cè)攔截器配置,解決了第一個(gè)問(wèn)題的疑惑:

public void addInterceptors(InterceptorRegistry registry) {
    // 添加攔截器，去除對(duì)登錄的攔截
    registry.addInterceptor(authInterceptor)
    .excludePathPatterns("/user/login")
    .excludePathPatterns("/user/wechatLogin");
  }

這個(gè)異常是用戶登錄時(shí)拋出的，在注冊(cè)時(shí)將登錄路徑給忽略了，因?yàn)槲覀冎皇菙r截未登錄的請(qǐng)求，而請(qǐng)求登錄的請(qǐng)求不應(yīng)該攔截，這是正確的，但第二點(diǎn)卻怎么也不明白，本應(yīng)忽略攔截的請(qǐng)求，為什么換了sendError()方法后，卻在異常處理完畢后經(jīng)過(guò)了異常攔截器?

springboot的默認(rèn)異常處理

對(duì)比兩個(gè)方法的不同:setStatus()只是改了一下狀態(tài)嗎,而sendError()還有請(qǐng)求錯(cuò)誤的意味，于是猜想是不是請(qǐng)求錯(cuò)誤才會(huì)出現(xiàn)這種情況,將方法直接改為throw new RuntimeException()(沒(méi)有處理異常),發(fā)現(xiàn)攔截器攔截的請(qǐng)求的url居然是一個(gè)/error的url.

這個(gè)/error的url并未在項(xiàng)目中定義過(guò)任何的控制器中，也從未發(fā)起這樣的請(qǐng)求，上網(wǎng)一查詢,原來(lái)這是Spring Boot提供了一個(gè)默認(rèn)的映射：/error，當(dāng)處理中拋出異常之后，會(huì)轉(zhuǎn)到該請(qǐng)求中處理，并且該請(qǐng)求有一個(gè)全局的錯(cuò)誤頁(yè)面用來(lái)展示異常內(nèi)容.
但是我們的攔截器把這個(gè)請(qǐng)求攔截了(并且這個(gè)請(qǐng)求沒(méi)有攜帶正確的cookie)，所以直接就返回了401錯(cuò)誤,response中也沒(méi)有我們定義的狀態(tài)碼和信息了.

json還是html

一切真相大白了，但忽然想到如果是瀏覽器發(fā)起的請(qǐng)求，服務(wù)器錯(cuò)誤后springboot默認(rèn)異常處理返回的是html，但是如果像我們前后臺(tái)分離的請(qǐng)求，返回就不應(yīng)該是html而是json的錯(cuò)誤信息了，這個(gè)要怎么區(qū)分呢？
使用google插件發(fā)送請(qǐng)求，返回的body是這樣的:

而用瀏覽器發(fā)起的請(qǐng)求返回的卻是一個(gè)html頁(yè)面:

<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>

仔細(xì)查看兩者發(fā)起的請(qǐng)求不同,在瀏覽器發(fā)起請(qǐng)求信息requestheader上發(fā)現(xiàn)了Accept字段:

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8

頓時(shí)就明白了,在發(fā)送請(qǐng)求時(shí)spring-boot根據(jù)Accept字段來(lái)給你返回響應(yīng)的內(nèi)容,例如application/json返回json，text/html返回html，真是感嘆spring-boot真是太周全了.

總結(jié)

spring-boot好心幫你默認(rèn)請(qǐng)求異常，但是卻給你帶來(lái)了麻煩，感覺(jué)還是自己理解的不夠多，學(xué)習(xí)路還遠(yuǎn)著呢。

以上就是本文的全部?jī)?nèi)容，希望對(duì)大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。

您可能感興趣的文章:

亚洲乱码中文字幕综合,中国熟女仑乱hd,亚洲精品乱拍国产一区二区三区,一本大道卡一卡二卡三乱码全集资源,又粗又黄又硬又爽的免费视频

spring boot 默認(rèn)異常處理的實(shí)現(xiàn)

相關(guān)文章

最新評(píng)論

大家感興趣的內(nèi)容

最近更新的內(nèi)容

常用在線小工具