同僚的代碼簡直沒法看，我來教你如何更優雅的設計Java異常

異常處理是程式開發中必不可少操作之一，但如何正确優雅的對異常進行處理确是一門學問，筆者根據自己的開發經驗來談一談我是如何對異常進行處理的。

由于本文隻作一些經驗之談，不涉及到基礎知識部分，如果讀者對異常的概念還很模糊，請先檢視基礎知識。

正如我們所知道的，java中的異常的超類是java.lang.Throwable(後文省略為Throwable),它有兩個比較重要的子類,java.lang.Exception(後文省略為Exception)和java.lang.Error(後文省略為Error)，其中Error由JVM虛拟機進行管理,如我們所熟知的OutOfMemoryError異常等，是以我們本文不關注Error異常，那麼我們細說一下Exception異常。

Exception異常有個比較重要的子類，叫做RuntimeException。我們将RuntimeException或其他繼承自RuntimeException的子類稱為非受檢異常(unchecked Exception)，其他繼承自Exception異常的子類稱為受檢異常(checked Exception)。本文重點來關注一下受檢異常和非受檢異常這兩種異常。

從筆者的開發經驗來看，如果在一個應用中，需要開發一個方法(如某個功能的service方法)，這個方法如果中間可能出現異常，那麼你需要考慮這個異常出現之後是否調用者可以處理，并且你是否希望調用者進行處理，如果調用者可以處理，并且你也希望調用者進行處理，那麼就要抛出受檢異常，提醒調用者在使用你的方法時，考慮到如果抛出異常時如果進行處理。

相似的，如果在寫某個方法時，你認為這是個偶然異常，理論上說，你覺得運作時可能會碰到什麼問題，而這些問題也許不是必然發生的，也不需要調用者顯示的通過異常來判斷業務流程操作的，那麼這時就可以使用一個RuntimeException這樣的非受檢異常.

好了，估計我上邊說的這段話，你讀了很多遍也依然覺得晦澀了。

那麼，請跟着我的思路，在慢慢領會一下。

首先我們需要了解一個問題，什麼時候才需要抛異常？異常的設計是友善給開發者使用的，但不是亂用的，筆者對于什麼時候抛異常這個問題也問了很多朋友，能給出準确答案的确實不多。其實這個問題很簡單，如果你覺得某些”問題”解決不了了，那麼你就可以抛出異常了。

比如，你在寫一個service,其中在寫到某段代碼處,你發現可能會産生問題，那麼就請抛出異常吧，相信我，你此時抛出異常将是一個最佳時機。

了解完了什麼時候才需要抛出異常後，我們再思考一個問題，真的當我們抛出異常時，我們應該選用怎樣的異常呢？究竟是受檢異常還是非受檢異常呢(RuntimeException)呢？

我來舉例說明一下這個問題，先從受檢異常說起,比如說有這樣一個業務邏輯，需要從某檔案中讀取某個資料，這個讀取操作可能是由于檔案被删除等其他問題導緻無法擷取進而出現讀取錯誤，那麼就要從redis或mysql資料庫中再去擷取此資料,參考如下代碼，getKey(Integer)為入口程式.

ok，看了以上代碼以後，你也許心中有一些想法，原來受檢異常可以控制義務邏輯，對，沒錯，通過受檢異常真的可以控制業務邏輯，但是切記不要這樣使用，我們應該合理的抛出異常，因為程式本身才是流程，異常的作用僅僅是當你進行不下去的時候找到的一個借口而已，它并不能當成控制程式流程的入口或出口，如果這樣使用的話，是在将異常的作用擴大化，這樣将會導緻代碼複雜程度的增加，耦合性會提高，代碼可讀性降低等問題。

那麼就一定不要使用這樣的異常嗎？其實也不是，在真的有這樣的需求的時候，我們可以這樣使用，隻是切記，不要把它真的當成控制流程的工具或手段。那麼究竟什麼時候才要抛出這樣的異常呢？要考慮，如果調用者調用出錯後，一定要讓調用者對此錯誤進行處理才可以，滿足這樣的要求時，我們才會考慮使用受檢異常。

接下來，我們來看一下非受檢異常呢(RuntimeException)，對于RuntimeException這種異常，我們其實很多見，比如java.lang.NullPointerException／java.lang.IllegalArgumentException等，那麼這種異常我們時候抛出呢？

當我們在寫某個方法的時候，可能會偶然遇到某個錯誤，我們認為這個問題時運作時可能為發生的，并且理論上講，沒有這個問題的話，程式将會正常執行的時候，它不強制要求調用者一定要捕獲這個異常，此時抛出RuntimeException異常。

舉個例子，當傳來一個路徑的時候，需要傳回一個路徑對應的File對象:

上述例子表明，如果調用者調用getFiles(String)的時候如果path是空，那麼就抛出空指針異常(它是RuntimeException的子類),調用者不用顯示的進行try…catch…操作進行強制處理.這就要求調用者在調用這樣的方法時先進行驗證，避免發生RuntimeException.如下:

通過以上的描述和舉例，可以總結出一個結論，**RuntimeException異常和受檢異常之間的差別就是:是否強制要求調用者必須處理此異常，如果強制要求調用者必須進行處理，那麼就使用受檢異常，否則就選擇非受檢異常(RuntimeException)。**一般來講，如果沒有特殊的要求，我們建議使用RuntimeException異常。

正如我們所知，傳統的項目都是以MVC架構為基礎進行開發的，本文主要從使用restful風格接口的設計來體驗一下異常處理的優雅。

我們把關注點放在restful的api層(和web中的controller層類似)和service層，研究一下在service中如何抛出異常，然後api層如何進行捕獲并且轉化異常。

使用的技術是:spring-boot,jpa(hibernate),mysql,如果對這些技術不是太熟悉，讀者需要自行閱讀相關材料。

選擇一個比較簡單的業務場景，以電商中的收貨位址管理為例，使用者在移動端進行購買商品時，需要進行收貨位址管理，在項目中，提供一些給移動端進行通路的api接口，如:添加收貨位址，删除收貨位址，更改收貨位址，預設收貨位址設定，收貨位址清單查詢，單個收貨位址查詢等接口。

ok，這個是設定好的一個很基本的業務場景，當然，無論什麼樣的api操作，其中都包含一些規則:

添加收貨位址: 入參:

使用者id

收貨位址實體資訊

限制:

使用者id不能為空，且此使用者确實是存在 的

收貨位址的必要字段不能為 空

如果使用者還沒有收貨位址，當此收貨位址建立時設定成預設收貨位址 —

删除收貨位址: 入參:

收貨位址id

使用者id不能為空，且此使用者确實是存在的

收貨位址不能為空，且此收貨位址确實是存在的

判斷此收貨位址是否是使用者的收貨位址

判斷此收貨位址是否為預設收貨位址，如果是預設收貨位址，那麼不能進行删除

更改收貨位址: 入參:

預設位址設定: 入參:

收貨位址清單查詢: 入參:

單個收貨位址查詢: 入參:

對于上述列出的限制條件和功能清單，我選擇幾個比較典型的異常處理場景進行分析:添加收貨位址，删除收貨位址，擷取收貨位址清單。

那麼應該有哪些必要的知識儲備呢，讓我們看一下收貨位址這個功能:

添加收貨位址中需要對使用者id和收貨位址實體資訊就行校驗，那麼對于非空的判斷，我們如何進行工具的選擇呢？傳統的判斷如下:

上邊的例子，如果隻判斷uid為空還好，如果再去判斷address這個實體中的某些必要屬性是否為空，在字段很多的情況下，這無非是災難性的。

那我們應該怎麼進行這些入參的判斷呢，給大家介紹兩個知識點:

Guava中的Preconditions類實作了很多入參方法的判斷

jsr 303的validation規範(目前實作比較全的是hibernate實作的hibernate-validator)

如果使用了這兩種推薦技術，那麼入參的判斷會變得簡單很多。**推薦大家多使用這些成熟的技術和jar工具包，他可以減少很多不必要的工作量。****我們隻需要把重心放到業務邏輯上。**而不會因為這些入參的判斷耽誤更多的時間。

根據項目場景來看，需要兩個domain模型，一個是使用者實體，一個是位址實體.

Address domain如下:

User domain如下:

ok,上邊是一個模型關系，使用者-收貨位址的關系是1-n的關系。上邊的@Data是使用了一個叫做lombok的工具，它自動生成了Setter和Getter等方法，用起來非常友善，感興趣的讀者可以自行了解一下。

資料連接配接層，我們使用了spring-data-jpa這個架構，它要求我們隻需要繼承架構提供的接口，并且按照約定對方法進行取名，就可以完成我們想要的資料庫操作。

使用者資料庫操作如下:

收貨位址操作如下:

正如讀者所看到的，我們的DAO隻需要繼承JpaRepository,它就已經幫我們完成了基本的CURD等操作，如果想了解更多關于spring-data的這個項目，請參考一下spring的官方文檔，它比不方案我們對異常的研究。

ok，終于到了我們的重點了，我們要完成service一些的部分操作:添加收貨位址，删除收貨位址，擷取收貨位址清單.

首先看我的service接口定義:

我們來關注一下實作:

首先再來看一下之前整理的限制條件:

入參:

收貨位址的必要字段不能為空

如果使用者還沒有收貨位址，當此收貨位址建立時設定成預設收貨位址

先看以下代碼實作:

其中，已經完成了上述所描述的三點限制條件，當三點限制條件都滿足時，才可以進行正常的業務邏輯，否則将抛出異常(一般在此處建議抛出運作時異常-RuntimeException)。

介紹以下以上我所用到的技術:

1、Preconfitions.checkNotNull(T t)這個是使用Guava中的com.google.common.base.Preconditions進行判斷的，因為service中用到的驗證較多，是以建議将Preconfitions改成靜态導入的方式:

當然Guava的github中的說明也建議我們這樣使用。

2、BeanValidators.validateWithException(validator, address); 這個使用了hibernate實作的jsr 303規範來做的，需要傳入一個validator和一個需要驗證的實體,那麼validator是如何擷取的呢,如下:

他将擷取一個Validator對象，然後我們在service中進行注入便可以使用了:

那麼BeanValidators這個類是如何實作的？其實實作方式很簡單，隻要去判斷jsr 303的标注注解就ok了。

那麼jsr 303的注解寫在哪裡了呢？當然是寫在address實體類中了:

寫好你需要的限制條件來進行判斷，如果合理的話，才可以進行業務操作，進而對資料庫進行操作。

這塊的驗證是必須的，一個最主要的原因是:這樣的驗證可以避免髒資料的插入。

如果讀者有正式上線的經驗的話，就可以了解這樣的一個事情，**任何的代碼錯誤都可以容忍和修改，但是如果出現了髒資料問題，那麼它有可能是一個毀滅性的災難。**程式的問題可以修改，但是髒資料的出現有可能無法恢複。是以這就是為什麼在service中一定要判斷好限制條件，再進行業務邏輯操作的原因了。

此處的判斷為業務邏輯判斷，是從業務角度來進行篩選判斷的，除此之外，有可能在很多場景中都會有不同的業務條件限制，隻需要按照要求來做就好。

對于限制條件的總結如下:

基本判斷限制(null值等基本判斷)

實體屬性限制(滿足jsr 303等基礎判斷)

業務條件限制(需求提出的不同的業務限制)

當這個三點都滿足時，才可以進行下一步操作

ok,基本介紹了如何做一個基礎的判斷，那麼再回到異常的設計問題上，上述代碼已經很清楚的描述如何在适當的位置合理的判斷一個異常了，那麼如何合理的抛出異常呢？

隻抛出RuntimeException就算是優雅的抛出異常嗎？當然不是，對于service中的抛出異常，筆者認為大緻有兩種抛出的方法:

抛出帶狀态碼RumtimeException異常

抛出指定類型的RuntimeException異常

相對這兩種異常的方式進行結束，第一種異常指的是我所有的異常都抛RuntimeException異常，但是需要帶一個狀态碼，調用者可以根據狀态碼再去查詢究竟service抛出了一個什麼樣的異常。

第二種異常是指在service中抛出什麼樣的異常就自定義一個指定的異常錯誤，然後在進行抛出異常。

一般來講，如果系統沒有别的特殊需求的時候，在開發設計中，建議使用第二種方式。但是比如說像基礎判斷的異常，就可以完全使用guava給我們提供的類庫進行操作。jsr 303異常也可以使用自己封裝好的異常判斷類進行操作，因為這兩種異常都是屬于基礎判斷，不需要為它們指定特殊的異常。但是對于第三點義務條件限制判斷抛出的異常，就需要抛出指定類型的異常了。

對于

定義一個特定的異常類來進行這個義務異常的判斷:

然後将此處改為:

ok,通過以上對service層的修改，代碼更改如下:

這樣的service就看起來穩定性和了解性就比較強了。

它與上述添加收貨位址類似，故不再贅述，delete的service設計如下:

設計了相關的四個異常類:<code>NotFindUserException,NotFindAddressException,NotMatchUserAddressException,DefaultAddressNotDeleteException.</code>根據不同的業務需求抛出不同的異常。

擷取收貨位址清單:入參:

代碼如下:

大緻有兩種抛出的方法:

這個是在設計service層異常時提到的，通過對service層的介紹，我們在service層抛出異常時選擇了第二種抛出的方式，不同的是，在api層抛出異常我們需要使用這兩種方式進行抛出:要指定api異常的類型，并且要指定相關的狀态碼，然後才将異常抛出，這種異常設計的核心是讓調用api的使用者更能清楚的了解發生異常的詳細資訊。

除了抛出異常外，我們還需要将狀态碼對應的異常詳細資訊以及異常有可能發生的問題制作成一個對應的表展示給使用者，友善使用者的查詢。（如github提供的api文檔，微信提供的api文檔等）,還有一個好處:如果使用者需要自定義提示消息，可以根據傳回的狀态碼進行提示的修改。

首先對于api的設計來說，需要存在一個dto對象，這個對象負責和調用者進行資料的溝通和傳遞，然後dto-&gt;domain在傳給service進行操作，這一點一定要注意。

第二點，除了說道的service需要進行基礎判斷(null判斷)和jsr 303驗證以外，同樣的，api層也需要進行相關的驗證，如果驗證不通過的話，直接傳回給調用者，告知調用失敗，不應該帶着不合法的資料再進行對service的通路。

那麼讀者可能會有些迷惑，不是service已經進行驗證了，為什麼api層還需要進行驗證麼？這裡便設計到了一個概念:程式設計中的墨菲定律，如果api層的資料驗證疏忽了，那麼有可能不合法資料就帶到了service層，進而講髒資料儲存到了資料庫。

是以缜密程式設計的核心是:永遠不要相信收到的資料是合法的。

設計api層異常時，正如我們上邊所說的，需要提供錯誤碼和錯誤資訊，那麼可以這樣設計，提供一個通用的api超類異常，其他不同的api異常都繼承自這個超類:

然後分别定義api層異常：<code>ApiDefaultAddressNotDeleteException,ApiNotFindAddressException,ApiNotFindUserException,ApiNotMatchUserAddressException</code>以預設位址不能删除為例:

<code>AddressErrorCode.DefaultAddressNotDeleteErrorCode</code>就是需要提供給調用者的錯誤碼。錯誤碼類如下:

ok,那麼api層的異常就已經設計完了，在此多說一句，AddressErrorCode錯誤碼類存放了可能出現的錯誤碼，更合理的做法是把他放到配置檔案中進行管理。

api層會調用service層，然後來處理service中出現的所有異常，首先，需要保證一點，一定要讓api層非常輕，基本上做成一個轉發的功能就好(接口參數，傳遞給service參數，傳回給調用者資料,這三個基本功能)，然後就要在傳遞給service參數的那個方法調用上進行異常處理。

此處僅以添加位址為例:

這裡的處理方案是調用service時，判斷異常的類型，然後将任何service異常都轉化成api異常，然後抛出api異常，這是常用的一種異常轉化方式。相似删除收貨位址和擷取收貨位址也類似這樣處理，在此，不在贅述。

已經講解了如何抛出異常和何如将service異常轉化為api異常，那麼轉化成api異常直接抛出是否就完成了異常處理呢？答案是否定的，當抛出api異常後，我們需要把api異常傳回的資料(json or xml)讓使用者看懂，那麼需要把api異常轉化成dto對象(ErrorDTO),看如下代碼:

ok,這樣就完成了api異常轉化成使用者可以讀懂的DTO對象了，代碼中用到了@ControllerAdvice，這是spring MVC提供的一個特殊的切面處理。

當調用api接口發生異常時，使用者也可以收到正常的資料格式了,比如當沒有使用者(uid為2)時，卻為這個使用者添加收貨位址,postman(Google plugin 用于模拟http請求)之後的資料:

本文隻從如何設計異常作為重點來講解，涉及到的api傳輸和service的處理，還有待優化，比如api接口通路需要使用https進行加密，api接口需要OAuth2.0授權或api接口需要簽名認證等問題，文中都未曾提到，本文的重心在于異常如何處理，是以讀者隻需關注涉及到異常相關的問題和處理方式就可以了。

來源 | https://lrwinx.github.io/