導語異常處理是程式開發中必不可少操作之一，但如何正確優雅的對異常進行處理確是一門學問，筆者根據自己的開發經驗來談一談我是如何對異常進行處理的。由於本文只作一些經驗之談，不涉及到基礎知識部分，如果讀者對異常的概念還很模糊，請先檢視基礎知識。如何選擇異常型別異常的類別正如我們所知道的，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)為入口程式.public String getKey(Integer key){
String value;
try {
InputStream inputStream = getFiles(“/file/nofile”);
//接下來從流中讀取key的value指
value = …;
} catch (Exception e) {
//如果丟擲異常將從mysql或者redis進行取之
value = …;
}
}

public InputStream getFiles(String path) throws Exception {
File file = new File(path);
InputStream inputStream = null;
try {
inputStream = new BufferedInputStream(new FileInputStream(file));
} catch (FileNotFoundException e) {
throw new Exception(“I/O讀取錯誤”,e.getCause());
}
return inputStream;
}
ok，看了以上程式碼以後，你也許心中有一些想法，原來受檢異常可以控制義務邏輯，對，沒錯，通過受檢異常真的可以控制業務邏輯，但是切記不要這樣使用，我們應該合理的丟擲異常，因為程式本身才是流程，異常的作用僅僅是當你進行不下去的時候找到的一個藉口而已，它並不能當成控制程式流程的入口或出口，如果這樣使用的話，是在將異常的作用擴大化，這樣將會導致程式碼複雜程度的增加，耦合性會提高，程式碼可讀性降低等問題。那麼就一定不要使用這樣的異常嗎？其實也不是，在真的有這樣的需求的時候，我們可以這樣使用，只是切記，不要把它真的當成控制流程的工具或手段。那麼究竟什麼時候才要丟擲這樣的異常呢？要考慮，如果呼叫者調用出錯後，一定要讓呼叫者對此錯誤進行處理才可以，滿足這樣的要求時，我們才會考慮使用受檢異常。接下來，我們來看一下非受檢異常呢(RuntimeException)，對於RuntimeException這種異常，我們其實很多見，比如java.lang.NullPointerException／java.lang.IllegalArgumentException等，那麼這種異常我們時候丟擲呢？當我們在寫某個方法的時候，可能會偶然遇到某個錯誤，我們認為這個問題時執行時可能為發生的，並且理論上講，沒有這個問題的話，程式將會正常執行的時候，它不強制要求呼叫者一定要捕獲這個異常，此時丟擲RuntimeException異常,舉個例子，當傳來一個路徑的時候，需要返回一個路徑對應的File物件:public void test() {
myTest.getFiles(“”);
}

public File getFiles(String path) {
if(null == path || “”.equals(path)){
throw new NullPointerException(“路徑不能為空!”);
}
File file = new File(path);

return file;

}
上述例子表明，如果呼叫者呼叫getFiles(String)的時候如果path是空，那麼就丟擲空指標異常(它是RuntimeException的子類),呼叫者不用顯示的進行try…catch…操作進行強制處理.這就要求呼叫者在呼叫這樣的方法時先進行驗證，避免發生RuntimeException.如下:public void test() {
String path = “/a/b.png”;
if(null != path && !”“.equals(path)){
myTest.getFiles(“”);
}
}

public File getFiles(String path) {
if(null == path || “”.equals(path)){
throw new NullPointerException(“路徑不能為空!”);
}
File file = new File(path);

return file;

}
應該選用哪種異常通過以上的描述和舉例，可以總結出一個結論，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和收貨地址實體資訊就行校驗，那麼對於非空的判斷，我們如何進行工具的選擇呢？傳統的判斷如下:/**
* 新增地址
* @param uid
* @param address
* @return
*/
public Address addAddress(Integer uid,Address address){
if(null != uid){
//進行處理..
}
return null;
}
上邊的例子，如果只判斷uid為空還好，如果再去判斷address這個實體中的某些必要屬性是否為空，在欄位很多的情況下，這無非是災難性的。那我們應該怎麼進行這些入參的判斷呢，給大家介紹兩個知識點:Guava中的Preconditions類實現了很多入參方法的判斷jsr 303的validation規範(目前實現比較全的是hibernate實現的hibernate-validator)如果使用了這兩種推薦技術，那麼入參的判斷會變得簡單很多。推薦大家多使用這些成熟的技術和jar工具包，他可以減少很多不必要的工作量。我們只需要把重心放到業務邏輯上。而不會因為這些入參的判斷耽誤更多的時間。如何優雅的設計java異常domain介紹根據專案場景來看，需要兩個domain模型，一個是使用者實體，一個是地址實體.Address domain如下:@Entity
@Data
public class Address {
@Id
@GeneratedValue
private Integer id;
private String province;//省
private String city;//市
private String county;//區
private Boolean isDefault;//是否是預設地址

@ManyToOne(cascade={CascadeType.ALL})
@JoinColumn(name="uid")
private User user;

}
User domain如下:@Entity
@Data
public class User {
@Id
@GeneratedValue
private Integer id;
private String name;//姓名

@OneToMany(cascade= CascadeType.ALL,mappedBy="user",fetch = FetchType.LAZY)
    private Set<Address> addresses;

}
ok,上邊是一個模型關係，使用者-收貨地址的關係是1-n的關係。上邊的@Data是使用了一個叫做lombok的工具，它自動生成了Setter和Getter等方法，用起來非常方便，感興趣的讀者可以自行了解一下。dao介紹資料連線層，我們使用了spring-data-jpa這個框架，它要求我們只需要繼承框架提供的介面，並且按照約定對方法進行取名，就可以完成我們想要的資料庫操作。使用者資料庫操作如下:@Repository
public interface IUserDao extends JpaRepository