1，我看開源中國的很多原始碼，比如負責從網路解析資料，從資料庫的操作都拋異常。這麼做的原因是什麼。 2，是不是通常情況下，返回值是void的方法一般都丟擲異常（如果有的話），有返回值的就在內部try，catch，然後透過返回值標識這個方法是不是執行成功。比如返回值是String時，就約定返回""就是發生了異常， 3，A方法呼叫了B方法，B方法內部可能會產生IOException，B方法是帶有返回值的，A方法的內部也會有其他的操作產生IOException，這時候，讓B方法丟擲一個IOException，是不是便於在A方法中的catch中集中處理 4，一段邏輯，可能會產生A異常，解析json異常，IOExceptoin，這些異常都是IOException的子類，這時候是都catch，還是隻捕獲IOException 5.還看過一種寫法，比如要catch A，B,C，D異常，結果他只是catch Exception，然後在內部throw new RuntimeException，能這麼做的依據是什麼 6.《effective 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更改收貨地址: 入參:收貨地址id使用者id不能為空，且此使用者確實是存在的使用者id 約束:收貨地址不能為空，且此收貨地址確實是存在的判斷此收貨地址是否是使用者的收貨地址預設地址設定: 入參: 約束:收貨地址不能為空，且此收貨地址確實是存在的判斷此收貨地址是否是使用者的收貨地址使用者id不能為空，且此使用者確實是存在的使用者id收貨地址id收貨地址列表查詢: 入參:使用者id 約束:使用者id不能為空，且此使用者確實是存在的單個收貨地址查詢: 入參:收貨地址id使用者id不能為空，且此使用者確實是存在的使用者id 約束:收貨地址不能為空，且此收貨地址確實是存在的判斷此收貨地址是否是使用者的收貨地址

約束判斷和技術選型

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

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

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

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

Guava中的Preconditions類實現了很多入參方法的判斷jsr 303的validation規範(目前實現比較全的是hibernate實現的hibernate-validator) 如果使用了這兩種推薦技術，那麼入參的判斷會變得簡單很多。推薦大家多使用這些成熟的技術和jar工具包，他可以減少很多不必要的工作量。我們只需要把重心放到業務邏輯上。而不會因為這些入參的判斷耽誤更多的時間。

如何優雅的設計 Java 異常

domain介紹

根據專案場景來看，需要兩個domain模型，一個是使用者實體，一個是地址實體.

Address domain如下:

User domain如下:

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

dao介紹

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

使用者資料庫操作如下:

收貨地址操作如下:

Service異常設計

首先看我的service介面定義:

新增收貨地址

首先再來看一下之前整理的約束條件:

入參:

使用者id收貨地址實體資訊

約束:

使用者id不能為空，且此使用者確實是存在的收貨地址的必要欄位不能為空如果使用者還沒有收貨地址，當此收貨地址建立時設定成預設收貨地址

先看以下程式碼實現:

其中，已經完成了上述所描述的三點約束條件，當三點約束條件都滿足時，才可以進行正常的業務邏輯，否則將丟擲異常(一般在此處建議丟擲執行時異常-RuntimeException)。

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

Preconfitions.checkNotNull(T t)這個是使用Guava中的com.google.common.base.Preconditions進行判斷的，因為service中用到的驗證較多，所以建議將Preconfitions改成靜態匯入的方式:當然Guava的github中的說明也建議我們這樣使用。BeanValidators.validateWithException(validator, address); 這個使用了hibernate實現的jsr 303規範來做的，需要傳入一個validator和一個需要驗證的實體,那麼validator是如何獲取的呢,如下:

@Configuration

public class BeanConfigs {

@Bean

public javax.validation.Validator getValidator(){

return new LocalValidatorFactoryBean();

}

}

他將獲取一個Validator物件，然後我們在service中進行注入便可以使用了:

那麼BeanValidators這個類是如何實現的？其實實現方式很簡單，只要去判斷jsr 303的標註註解就ok了。

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

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

這塊的驗證是必須的，一個最主要的原因是:這樣的驗證可以避免髒資料的插入。如果讀者有正式上線的經驗的話，就可以理解這樣的一個事情，任何的程式碼錯誤都可以容忍和修改，但是如果出現了髒資料問題，那麼它有可能是一個毀滅性的災難。程式的問題可以修改，但是髒資料的出現有可能無法恢復。所以這就是為什麼在service中一定要判斷好約束條件，再進行業務邏輯操作的原因了。

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

對於約束條件的總結如下:

基本判斷約束(null值等基本判斷)實體屬性約束(滿足jsr 303等基礎判斷)業務條件約束(需求提出的不同的業務約束)

當這個三點都滿足時，才可以進行下一步操作ok,基本介紹瞭如何做一個基礎的判斷，那麼再回到異常的設計問題上，上述程式碼已經很清楚的描述如何在適當的位置合理的判斷一個異常了，那麼如何合理的丟擲異常呢？

只丟擲RuntimeException就算是優雅的丟擲異常嗎？當然不是，對於service中的丟擲異常，筆者認為大致有兩種丟擲的方法:

丟擲帶狀態碼RumtimeException異常丟擲指定型別的RuntimeException異常

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

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

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

對於

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

然後將此處改為:

or

ok,透過以上對service層的修改，程式碼更改如下:

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

使用者id收貨地址id

約束:

使用者id不能為空，且此使用者確實是存在的收貨地址不能為空，且此收貨地址確實是存在的判斷此收貨地址是否是使用者的收貨地址判斷此收貨地址是否為預設收貨地址，如果是預設收貨地址，那麼不能進行刪除

它與上述新增收貨地址類似，故不再贅述，delete的service設計如下:

設計了相關的四個異常類:NotFindUserException,NotFindAddressException,NotMatchUserAddressException,DefaultAddressNotDeleteException.根據不同的業務需求丟擲不同的異常。

獲取收貨地址列表

入參:

使用者id

約束:

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

程式碼如下:

api異常設計

大致有兩種丟擲的方法:

丟擲帶狀態碼RumtimeException異常丟擲指定型別的RuntimeException異常

這個是在設計service層異常時提到的，透過對service層的介紹，我們在service層丟擲異常時選擇了第二種丟擲的方式，不同的是，在api層丟擲異常我們需要使用這兩種方式進行丟擲:要指定api異常的型別，並且要指定相關的狀態碼，然後才將異常丟擲，這種異常設計的核心是讓呼叫api的使用者更能清楚的瞭解發生異常的詳細資訊。

除了丟擲異常外，我們還需要將狀態碼對應的異常詳細資訊以及異常有可能發生的問題製作成一個對應的表展示給使用者，方便使用者的查詢。（如github提供的api文件，微信提供的api文件等）,還有一個好處:如果使用者需要自定義提示訊息，可以根據返回的狀態碼進行提示的修改。

api驗證約束

首先對於api的設計來說，需要存在一個dto物件，這個物件負責和呼叫者進行資料的溝通和傳遞，然後dto->domain在傳給service進行操作，這一點一定要注意。

第二點，除了說道的service需要進行基礎判斷(null判斷)和jsr 303驗證以外，同樣的，api層也需要進行相關的驗證，如果驗證不透過的話，直接返回給呼叫者，告知呼叫失敗，不應該帶著不合法的資料再進行對service的訪問，那麼讀者可能會有些迷惑，不是service已經進行驗證了，為什麼api層還需要進行驗證麼？這裡便設計到了一個概念:程式設計中的墨菲定律，如果api層的資料驗證疏忽了，那麼有可能不合法資料就帶到了service層，進而講髒資料儲存到了資料庫。

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

api異常設計

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

public class ApiException extends RuntimeException {

protected Long errorCode ;

protected Object data ;

public ApiException(Long errorCode,String message,Object data,Throwable e){

super(message,e);

this.errorCode = errorCode ;

this.data = data ;

}

public ApiException(Long errorCode,String message,Object data){

this(errorCode,message,data,null);

}

public ApiException(Long errorCode,String message){

this(errorCode,message,null,null);

}

public ApiException(String message,Throwable e){

this(null,message,null,e);

}

public ApiException(){

}

public ApiException(Throwable e){

super(e);

}

public Long getErrorCode() {

return errorCode;

}

public void setErrorCode(Long errorCode) {

this.errorCode = errorCode;

}

public Object getData() {

return data;

}

public void setData(Object data) {

this.data = data;

}

}

然後分別定義api層異常：

ApiDefaultAddressNotDeleteException,ApiNotFindAddressException,ApiNotFindUserException,ApiNotMatchUserAddressException。

public class ApiDefaultAddressNotDeleteException extends ApiException {

public ApiDefaultAddressNotDeleteException(String message) {

super(AddressErrorCode.DefaultAddressNotDeleteErrorCode, message, null);

}

}

AddressErrorCode.DefaultAddressNotDeleteErrorCode就是需要提供給呼叫者的錯誤碼。錯誤碼類如下:

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

api處理異常

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

此處僅以新增地址為例:

api異常轉化

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

@ControllerAdvice(annotations = RestController.class)

class ApiExceptionHandlerAdvice {

/**

* Handle exceptions thrown by handlers.

*/

@ExceptionHandler(value = Exception.class)

@ResponseBody

public ResponseEntity<ErrorDTO> exception(Exception exception,HttpServletResponse response) {

ErrorDTO errorDTO = new ErrorDTO();

if(exception instanceof ApiException){//api異常

ApiException apiException = (ApiException)exception;

errorDTO.setErrorCode(apiException.getErrorCode());

}else{//未知異常

errorDTO.setErrorCode(0L);

}

errorDTO.setTip(exception.getMessage());

ResponseEntity<ErrorDTO> responseEntity = new ResponseEntity<>(errorDTO,HttpStatus.valueOf(response.getStatus()));

return responseEntity;

}

@Setter

@Getter

class ErrorDTO{

private Long errorCode;

private String tip;

}

}

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

當呼叫api介面發生異常時，使用者也可以收到正常的資料格式了,比如當沒有使用者(uid為2)時，卻為這個使用者新增收貨地址,postman(Google plugin 用於模擬http請求)之後的資料:

總結

只從如何設計異常作為重點來講解，涉及到的api傳輸和service的處理，還有待最佳化，比如api介面訪問需要使用https進行加密，api介面需要OAuth2.0授權或api介面需要簽名認證等問題，文中都未曾提到，重心在於異常如何處理，所以只需關注涉及到異常相關的問題和處理方式就可以了。

異常的類別

正如我們所知道的，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不能為空，且此使用者確實是存在的

收貨地址不能為空，且此收貨地址確實是存在的

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

更改收貨地址:入參:

使用者id

收貨地址id

約束:

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

收貨地址不能為空，且此收貨地址確實是存在的

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

預設地址設定:入參:

使用者id

收貨地址id

約束:

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

收貨地址不能為空，且此收貨地址確實是存在的

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

收貨地址列表查詢:入參:

使用者id

約束:

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

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

使用者id

收貨地址id

約束:

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

收貨地址不能為空，且此收貨地址確實是存在的

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

約束判斷和技術選型

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

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

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

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

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

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

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

如何優雅的設計java異常domain介紹

根據專案場景來看，需要兩個domain模型，一個是使用者實體，一個是地址實體.

Address domain如下:

User domain如下:

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

dao介紹

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

使用者資料庫操作如下:

收貨地址操作如下:

Service異常設計

首先看我的service介面定義:

新增收貨地址

首先再來看一下之前整理的約束條件:

入參:

使用者id

收貨地址實體資訊

約束:

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

收貨地址的必要欄位不能為空

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

先看以下程式碼實現:

其中，已經完成了上述所描述的三點約束條件，當三點約束條件都滿足時，才可以進行正常的業務邏輯，否則將丟擲異常(一般在此處建議丟擲執行時異常-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實體類中了:

java有23種設計模式，如果你想設計模式就需要對設計模式非常的精通，

java設計模式屬於高階教程，我們對設計模式已經進行 ，很詳細的講解，

可以領取影片教程、資料。也可以找我交流。