最近在用spring boot 做微服務，所以對於異常信息的 【友好展示】有要求，我設計了兩點：
一、 在業務邏輯代碼中，異常的拋出 我做了限定，一般只會是三種：
1. OmcException //自己寫的異常包裝類 ，主要用來處理業務異常 2. IllegalArgumentException //參數異常類，其實這個可以不要，只是在我的系統中，我想把參數異常和業務異常做區分 3. 其他的異常，都按Exception拋 //因為它的抽象層次最高，所以在系統中按優先級最低進行處理，除非必要（如容器級錯誤）否則盡量避免
OmcException的構造是這樣的：
這里留個鈎子：
為什么要在拋異常時，帶上 日志的信息 + 輸入參數的信息？
—— 因為，我希望在業務邏輯代碼中，對於這些異常的處理，最好就是一行代碼，類似於：打印error日志 + 向用戶返回友好的錯誤信息。我想做一個公共的處理模塊。讓業務邏輯代碼盡可能的清爽一些。
對異常的進行try-catch包裝的過程是：
對異常的拋出做限定，給個總結就是：盡量包裝成我們自己封裝的異常包裝類。
為什么呢？ 這是在設計上做限定，那么后進的程序員，如果不按照這個規范走，功能是做不出來的。這個也是架構設計的意義，不要隨便動個嘴就好，還要把柵欄建好。
二、 在公共的業務邏輯處理代碼中，異常的接收（或者說異常的路由） 我做了限定，一般是：
1. 先匹配業務異常。業務異常一般向用戶提示什么呢？ 錯誤編碼 + 錯誤提示信息。
2. 其次，匹配參數異常，這些參數異常可能是我們自己做參數校驗拋出來的，也有可能是spring mvc 拋出來的，所以還沒有到我們的業務邏輯代碼中。
參數異常一般提示什么呢？ 錯誤提示信息（包含哪個字段出現了錯誤）
3. 根異常Exception，這里捕獲的異常，可能是我們不願意處理的 數據庫異常，也有可能是容器報的異常（當然，這些異常我們並不能捕獲所有的。）這里要做打error日志的處理。
一個設計良好的系統，最好是不要走進這個分支，畢竟分析error日志不是一件多么光榮的事兒。
spring boot中，公共異常處理模塊代碼結構是：
然后是，打印error日志 + 向用戶返回友好的錯誤信息
