其實web伺服器是會處理錯誤的


在web.xml還是隨處可見的年代時（確實有點老黃曆了），下面的這些配置應該都不陌生。

根據錯誤程式碼處理錯誤，如下圖01：

根據異常型別處理錯誤，如下圖02：

不過我們更加熟悉的應該是SpringMVC的統一異常處理。如下圖03：

看到@ControllerAdvice註解和@ExceptionHandler註解都應該很熟悉吧。

處理原理就是在捕獲到業務Controller有異常丟擲時，根據異常型別來這裡找到對應的方法並執行。

可見，整個異常的處理過程都是在SpringMVC內部給搞定了，根本就沒有涉及到web伺服器，如tomcat。

那麼問題來了，明明web伺服器可以處理異常，為啥SpringMVC還要自己處理呢？

是不想呢，還是另有苦衷


讀過本系列上一篇文章的小夥伴應該能猜出來一些。因為SpringMVC開發的工程最終打成war包，然後扔到tomcat下面即可。

而且SpringMVC和tomcat之間是通過Java Web的規範聯絡起來的，它們之間根本沒有辦法自由互動的。

然而tomcat的錯誤處理需要在web.xml裡面配置。嚴格來說，web.xml其實和SpringMVC關係不大。

特別是Spring全面進入Java和註解配置時代以後，web.xml逐漸被弱化，繼而變得可有可無，直到最終完全消失。

所以（我猜測）SpringMVC可能不希望自己的使用者到一個和自己關係不大的web.xml裡面配置一些和業務相關的異常處理對映。

所以只好自己把異常處理消化掉。不勞tomcat大駕。因此才有了SpringMVC統一處理異常。


重新讓web伺服器來處理錯誤


當歷史來到了SpringBoot的時代，SpringBoot翻身做主成了入口，web伺服器竟然成了一個元件。

SpringBoot可以操作web伺服器的API，通過程式設計的方式，對web伺服器進行深度配置。

所以很多事情都變得容易起來，比如錯誤處理。

因為web.xml裡的錯誤處理對映最終是註冊到tomcat裡面了，所以SpringBoot只要操作tomcat的API，使用程式設計的方式也來註冊一些錯誤處理對映不就可以了嘛。

因為使用者直接是和SpringBoot打交道的，所以SpringBoot需要抽象出一套錯誤處理註冊機制，讓使用者來註冊。

這樣SpringBoot拿到使用者註冊的錯誤處理對映資訊後，在生成web伺服器（如tomcat）時，把這些對映資訊新增到web伺服器中即可。


SpringBoot註冊錯誤處理對映的方案


先來看看錯誤處理對映是如何描述的，如下圖04：

三個欄位的含義是：

path是一個路徑，它表示的是錯誤處理的url。

status是一個狀態碼，如404、500等。

exception是一個異常型別，如LoginFailedException。

一共有三種使用方式：

1）status + path，如404 + /404，表示如果遇到了404，就去執行/404這個url。

2）exception + path，如LoginFailedException + /loginfailed，表示如果遇到登陸失敗異常，就去執行後面這個url

3）沒有status和exception，只有path，這相當於萬用字元，匹配所有異常情況。

接下來就該考慮如何註冊了，照例給個介面就行了，如下圖0506：

Spring是以bean打天下的，所以SpringBoot給的方法當然也是和bean相關。

只要向容器中註冊一個該介面型別的bean即可，如下圖07：

這些資訊會被收集到並存好，如下圖08：

然後在建立web伺服器時新增進去就行了，以tomcat為例，如下圖09：

可以看到最終轉換為tomcat的錯誤對映，如下圖10：

這裡的setLocation、setErrorCode、setExceptionType三個setter方法，就對應於web.xml裡的<location>、<error-code>、<exception-type>這三個標籤。

至此，錯誤處理已經被註冊好了。


SpringBoot仍需協助處理錯誤


有一點需要明白，SpringMVC交給tomcat的只是錯誤處理對映的匹配工作，但有些真正的錯誤處理還是要自己做的。

所以整個過程是這樣的，SpringMVC隨意丟擲異常，這個異常會被拋到tomcat裡面，tomcat獲取異常型別並根據註冊的錯誤處理對映關係找到一個url，然後呼叫這個url。

那麼請問這個url指向哪裡呢？很大概率又回到了SpringMVC裡面了，是不是很有意思，哈哈。

tomcat就像一面鏡子，SpringMVC向它發射了一束光線，經過反射後又回來了。只不過發射的是一個異常，回來的是一個url。

這個url對應的是能夠處理這個錯誤的一個Controller的方法。這樣執行這個Controller方法就等於處理了異常。

這個Controller是一個能夠處理錯誤的Controller，所以就叫ErrorController。如下圖11：

其實它主要是一個Marker介面，也就起一個標誌作用。

下面是真正用於處理錯誤的Controller，實現了剛剛的標誌介面，如下圖12：

@RequestMapping方法就是處理錯誤的，既可以返回JSON，也可以返回檢視頁面。

我們可以自己寫一個錯誤處理類，然後繼承這個類，新增自己的錯誤處理方法，最後使用@Controller註解重新註冊即可。

可以把一個異常對映成和它名稱一樣的url路徑，如把Exception對映為/Exception，如下圖13：

這兩個方法，一個返回html頁面，一個返回一個JSON。

備註：異常型別和它對映的url之間的關係，可以按自己的需求去規劃，統一規則即可。

處理錯誤時，自然要獲得錯誤相關資訊才行，這個介面可以滿足，如下圖14：

可以獲得錯誤屬性和丟擲的異常物件。

可以看到介面的兩個方法都有WebRequest這個引數，說明錯誤資訊是從request中獲取出來的。

同時也說明有些錯誤資訊是有人專門放入request中的，是SpringBoot放的，還是web伺服器放的？

其實都有，比如異常物件是SpringBoot放的，響應狀態碼是web伺服器（按Java web規範）放的。

這也說明web伺服器執行錯誤處理的url時用的是轉發（forward）而非重定向（redirect），因為要保留request中的資訊。

還剩最後一個，錯誤檢視解析器，如下圖15：

SpringBoot自己提供了預設的檢視解析器實現，預設去classpath下面的error目錄下尋找.html檢視頁面。

如下圖16：

支援狀態碼到頁面的對映，如404預設對映為/error/404.html，500預設對映為/error/500.html。

如果沒有這麼具體的頁面，還支援系列對映，如404對映為/error/4xx.html，500對映為5xx.html。

當然，預設的一般都無法滿足需求，我們可以繼承這個預設的類，然後重寫檢視解析方法。

最後把這個類註冊為bean即可，這樣SpringBoot就會使用我們的類了。如下圖17：

本文總結，重要


1）使用者使用SpringBoot提供的錯誤處理對映機制註冊狀態碼和異常的對映url資訊。

2）這些對映資訊最終會被註冊進web伺服器中，如tomcat。

3）SpringBoot把異常拋給web伺服器，web伺服器根據異常找到對應的url，並執行它。

4）流程再次回到SpringBoot中，進入錯誤處理Controller的方法中，執行錯誤處理方法。

5）如果需要解析檢視的，使用錯誤檢視解析器進行檢視解析。否則就是直接返回JSON。

其中使用者能參與的就三步，註冊異常對映，擴充套件錯誤處理Controller，擴充套件錯誤檢視解析器。

具體參與方式文章中都有，無非就是實現介面或繼承某個類，然後註冊為bean即可。

 

>>> 玩轉SpringBoot系列文章 <<<

 

【玩轉SpringBoot】配置檔案yml的正確開啟姿勢

【玩轉SpringBoot】用好條件相關注解，開啟自動配置之門

【玩轉SpringBoot】給自動配置來個整體大揭祕

【玩轉SpringBoot】看似複雜的Environment其實很簡單

【玩轉SpringBoot】翻身做主人，一統web伺服器

 

>>> 品Spring系列文章 <<<

 

品Spring：帝國的基石

品Spring：bean定義上梁山

品Spring：實現bean定義時採用的“先進生產力”

品Spring：註解終於“成功上位”

品Spring：能工巧匠們對註解的“加持”

品Spring：SpringBoot和Spring到底有沒有本質的不同？

品Spring：負責bean定義註冊的兩個“排頭兵”

品Spring：SpringBoot輕鬆取勝bean定義註冊的“第一階段”

品Spring：SpringBoot發起bean定義註冊的“二次攻堅戰”

品Spring：註解之王@Configuration和它的一眾“小弟們”

品Spring：bean工廠後處理器的呼叫規則

品Spring：詳細解說bean後處理器

品Spring：對@PostConstruct和@PreDestroy註解的處理方法

品Spring：對@Resource註解的處理方法

品Spring：對@Autowired和@Value註解的處理方法

品Spring：真沒想到，三十步才能完成一個bean例項的建立

品Spring：關於@Scheduled定時任務的思考與探索，結果尷尬了

 

>>> 熱門文章集錦 <<<

相關推薦