在具體的ssm專案開發中，由於controller層為處於請求處理的最頂層，再往上就是框架**的。
因此，肯定需要在controller捕獲所有異常，並且做適當處理，返回給前端乙個友好的錯誤碼。
不過，controller一多，我們發現每個controller裡都有大量重複的、冗餘的異常處理**，很是囉嗦。
能否將這些重複的部分抽取出來，這樣保證controller層更專注於業務邏輯的處理，
同時能夠使得異常的處理有乙個統一的控制中心點。
12345678910111213141516171819複製**使用全域性異常處理器只需要兩步：
實現handlerexceptionresolver介面。
將實現類作為spring bean，這樣spring就能掃瞄到它並作為全域性異常處理器載入。
在resolveexception中實現異常處理邏輯。
從引數上，可以看到，不僅能夠拿到發生異常的函式和異常物件，還能夠拿到httpservletresponse物件，從而控制本次請求返回給前端的行為。
此外，函式還可以返回乙個modelandview物件，表示渲染乙個檢視，比方說錯誤頁面。
不過，在前後端分離為主流架構的今天，這個很少用了。如果函式返回的檢視為空，則表示不需要檢視。
來看乙個例子：
12345678910111213141516171819202122232425複製**@component@slf4jpublic class customhandlerexceptionresolver implements handlerexceptionresolver log.error("[{}] system error", method, ex); responsedto response = responsedto.builder() .errorcode(errorcode.system_error) .build(); byte bytes = json.tojsonstring(response).getbytes(standardcharsets.utf_8)); try catch (ioexception e) return new modelandview(); }}複製**邏輯很顯然，在發生異常時，將responsedto序列化為json給前端。
這種異常處理只區域性於某個controller內，如：
1234567891011121314複製**使用上，在controller內部，用@exceptionhandler註解的方法，就會作為該controller內部的異常處理方法。
並且，它的引數中可以注入如webrequest、nativewebrequest等，用來拿到請求相關的資料。
它可以返回string代表乙個view名稱，也可以返回乙個物件並且用@responsebody修飾，由框架的其它機制幫你序列化。
此外，它還能夠對異常型別進行細粒度的控制，通過註解可以有選擇的指定異常處理方法應用的異常型別：
1複製**@exceptionhandler()複製**雖然說全域性異常處理handlerexceptionresolver通過條件判斷也能做到，
但是使用這種註解方式明顯更具有可讀性。
剛才說到異常處理函式可以用@responsebody修飾，就像一般的controller方法一樣。
然而，非常遺憾的是，如果使用自定義的handlermethodreturnvaluehandler，卻不生效。
比如：
12345678複製**@exceptionhandler(exception.class)@jsonresponsepublic responsedto<?> exceptionhandler(exception e) ] system error", e); return responsedto.builder() .errorcode(errorcode.system_error) .build();}複製**不知道是我的使用姿勢不對，還是什麼情況？各種google後無果。
所以，目前的解決方案是，如果能夠控制@jsonresponse註解相關的定義**，將處理返回值這部分邏輯抽取出來，然後在異常處理函式中手動呼叫。
剛才介紹的是controller區域性的異常處理，用於處理該controller內部的特有的異常處理十分有用。
首先，定義乙個存放異常處理函式的類，並使用@controlleradvice修飾。
123456789101112複製**@exceptionhanlder修飾的方法的寫法和controller內的異常處理函式寫法是一樣的。
注意到，我是這樣編寫註解的：
1複製**@controlleradvice(assignabletypes = )複製**它用來限定這些異常處理函式起作用的controller的範圍。如果不寫，則預設對所有controller有效。
這也是controlleradvice進行統一異常處理的優點，它能夠細粒度的控制該異常處理器針對哪些controller有效，這樣的好處是：
乙個系統裡就能夠存在不同的異常處理器，controller也可以有選擇的決定使用哪個，更加靈活。
不同的業務模組可能對異常處理的方式不同，通過該機制就能做到。
設想乙個一開始並未使用全域性異常處理的系統，如果直接引入全域性範圍內生效的全域性異常處理，勢必可能會改變已有controller的行為，有侵入性。
也就是說，如果不控制生效範圍，即預設對所有controller生效。如果控制生效範圍，則預設對所有controller不生效，降低侵入性。
如剛才示例中的例子，只針對實現了globalexceptionhandlermixin介面的類有效：
12345複製**controlleradvice支援的限定範圍：
按註解：@controlleradvice(annotations = restcontroller.class)按包名：@controlleradvice("org.example.controllers")按型別：@controlleradvice(assignabletypes = )
以上幾種方式是spring專門為異常處理設計的機制。
就我個人而言，由於controlleradvice具有更細粒度的控制能力，所以我更偏愛於在系統中使用controlleradvice進行統一異常處理。
除了用異常來傳遞系統中的意外錯誤，也會用它來傳遞處於介面行為一部分的業務錯誤。
這也是異常的優點之一，如果介面的實現比較複雜，分多層函式實現，如果直接傳遞錯誤碼，那麼到controller的路徑上的每一層函式都需要檢查錯誤碼，退回到了c語言那種可怕的「寫一行語句檢查一下錯誤碼」的模式。
當然，理論上，任何能夠給controller加切面的機制都能變相的進行統一異常處理。比如：
在***內捕獲controller的異常，做統一異常處理。
使用spring的aop機制，做統一異常處理。
統一異常處理
為什麼需要做統一異常處理 因為如果不做統一處理，返回與前端的資料會非常亂，前端不好處理 並且不做統一處理，controller層就要寫很多的重複 統一格式 實現步驟 新建result物件 也就是請求返回的整體物件，包括code,msg,data public class result public ...
統一異常處理
1，建立統一異常處理類package com.xindong.common.handler 統一異常處理類 controlleradvice public class globalexceptionhandler exceptionhandler badsqlgrammarexception.cla...
統一異常處理
controlleradvice 用於捕獲全域性異常 exceptionhandler 傳入指定異常類 controlleradvice public class globalexceptionhandler 指定什麼異常執行該方法 exception 所有異常 exceptionhandler a...