導(dǎo)語

異常處理是程序開發(fā)中必不可少操作之一凡橱，但如何正確優(yōu)雅的對異常進(jìn)行處理確是一門學(xué)問，筆者根據(jù)自己的開發(fā)經(jīng)驗(yàn)來談一談我是如何對異常進(jìn)行處理的恒序。
由于本文只作一些經(jīng)驗(yàn)之談衷咽，不涉及到基礎(chǔ)知識部分鸽扁，如果讀者對異常的概念還很模糊，請先查看基礎(chǔ)知識镶骗。

如何選擇異常類型

異常的類別

正如我們所知道的桶现，java中的異常的超類是java.lang.Throwable(后文省略為Throwable),它有兩個(gè)比較重要的子類,java.lang.Exception(后文省略為Exception)和java.lang.Error(后文省略為Error)，其中Error由JVM虛擬機(jī)進(jìn)行管理,如我們所熟知的OutOfMemoryError異常等鼎姊，所以我們本文不關(guān)注Error異常骡和，那么我們細(xì)說一下Exception異常。
Exception異常有個(gè)比較重要的子類相寇，叫做RuntimeException慰于。我們將RuntimeException或其他繼承自RuntimeException的子類稱為非受檢異常(unchecked Exception)，其他繼承自Exception異常的子類稱為受檢異常(checked Exception)唤衫。本文重點(diǎn)來關(guān)注一下受檢異常和非受檢異常這兩種異常婆赠。

如何選擇異常

從筆者的開發(fā)經(jīng)驗(yàn)來看，如果在一個(gè)應(yīng)用中佳励，需要開發(fā)一個(gè)方法(如某個(gè)功能的service方法)休里，這個(gè)方法如果中間可能出現(xiàn)異常，那么你需要考慮這個(gè)異常出現(xiàn)之后是否調(diào)用者可以處理赃承，并且你是否希望調(diào)用者進(jìn)行處理妙黍，如果調(diào)用者可以處理，并且你也希望調(diào)用者進(jìn)行處理瞧剖，那么就要拋出受檢異常拭嫁，提醒調(diào)用者在使用你的方法時(shí)，考慮到如果拋出異常時(shí)如果進(jìn)行處理抓于，相似的做粤，如果在寫某個(gè)方法時(shí)，你認(rèn)為這是個(gè)偶然異常毡咏，理論上說，你覺得運(yùn)行時(shí)可能會(huì)碰到什么問題逮刨，而這些問題也許不是必然發(fā)生的呕缭，也不需要調(diào)用者顯示的通過異常來判斷業(yè)務(wù)流程操作的堵泽，那么這時(shí)就可以使用一個(gè)RuntimeException這樣的非受檢異常.
好了，估計(jì)我上邊說的這段話恢总，你讀了很多遍也依然覺得晦澀了迎罗。
那么，請跟著我的思路片仿，在慢慢領(lǐng)會(huì)一下纹安。

什么時(shí)候才需要拋異常

首先我們需要了解一個(gè)問題，什么時(shí)候才需要拋異常砂豌？異常的設(shè)計(jì)是方便給開發(fā)者使用的厢岂，但不是亂用的，筆者對于什么時(shí)候拋異常這個(gè)問題也問了很多朋友阳距，能給出準(zhǔn)確答案的確實(shí)不多塔粒。其實(shí)這個(gè)問題很簡單，如果你覺得某些”問題”解決不了了筐摘，那么你就可以拋出異常了卒茬。比如，你在寫一個(gè)service,其中在寫到某段代碼處,你發(fā)現(xiàn)可能會(huì)產(chǎn)生問題咖熟，那么就請拋出異常吧圃酵，相信我，你此時(shí)拋出異常將是一個(gè)最佳時(shí)機(jī)馍管。

應(yīng)該拋出怎樣的異常

了解完了什么時(shí)候才需要拋出異常后郭赐，我們再思考一個(gè)問題，真的當(dāng)我們拋出異常時(shí)咽斧，我們應(yīng)該選用怎樣的異常呢堪置？究竟是受檢異常還是非受檢異常呢(RuntimeException)呢？我來舉例說明一下這個(gè)問題张惹，先從受檢異常說起,比如說有這樣一個(gè)業(yè)務(wù)邏輯舀锨，需要從某文件中讀取某個(gè)數(shù)據(jù)，這個(gè)讀取操作可能是由于文件被刪除等其他問題導(dǎo)致無法獲取從而出現(xiàn)讀取錯(cuò)誤宛逗，那么就要從redis或mysql數(shù)據(jù)庫中再去獲取此數(shù)據(jù),參考如下代碼坎匿，getKey(Integer)為入口程序.

public String getKey(Integer key){
    String  value;
    try {
        InputStream inputStream = getFiles("/file/nofile");
        //接下來從流中讀取key的value指
        value = ...;
    } catch (Exception e) {
        //如果拋出異常將從mysql或者redis進(jìn)行取之
        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讀取錯(cuò)誤",e.getCause());
    }
    return inputStream;
}

ok，看了以上代碼以后雷激，你也許心中有一些想法替蔬，原來受檢異常可以控制義務(wù)邏輯屎暇，對优俘，沒錯(cuò)矾飞，通過受檢異常真的可以控制業(yè)務(wù)邏輯，但是切記不要這樣使用谣蠢，我們應(yīng)該合理的拋出異常，因?yàn)槌绦虮旧聿攀橇鞒蹋惓５淖饔脙H僅是當(dāng)你進(jìn)行不下去的時(shí)候找到的一個(gè)借口而已，它并不能當(dāng)成控制程序流程的入口或出口，如果這樣使用的話酷麦，是在將異常的作用擴(kuò)大化，這樣將會(huì)導(dǎo)致代碼復(fù)雜程度的增加喉恋，耦合性會(huì)提高沃饶，代碼可讀性降低等問題。那么就一定不要使用這樣的異常嗎轻黑？其實(shí)也不是糊肤，在真的有這樣的需求的時(shí)候，我們可以這樣使用苔悦，只是切記轩褐，不要把它真的當(dāng)成控制流程的工具或手段。那么究竟什么時(shí)候才要拋出這樣的異常呢玖详？要考慮把介，如果調(diào)用者調(diào)用出錯(cuò)后，一定要讓調(diào)用者對此錯(cuò)誤進(jìn)行處理才可以蟋座，滿足這樣的要求時(shí)拗踢，我們才會(huì)考慮使用受檢異常。
接下來向臀，我們來看一下非受檢異常呢(RuntimeException)巢墅，對于RuntimeException這種異常，我們其實(shí)很多見券膀，比如java.lang.NullPointerException／java.lang.IllegalArgumentException等君纫，那么這種異常我們時(shí)候拋出呢？當(dāng)我們在寫某個(gè)方法的時(shí)候芹彬，可能會(huì)偶然遇到某個(gè)錯(cuò)誤蓄髓，我們認(rèn)為這個(gè)問題時(shí)運(yùn)行時(shí)可能為發(fā)生的，并且理論上講舒帮，沒有這個(gè)問題的話会喝，程序?qū)?huì)正常執(zhí)行的時(shí)候，它不強(qiáng)制要求調(diào)用者一定要捕獲這個(gè)異常玩郊，此時(shí)拋出RuntimeException異常,舉個(gè)例子肢执，當(dāng)傳來一個(gè)路徑的時(shí)候，需要返回一個(gè)路徑對應(yīng)的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;
}

上述例子表明译红，如果調(diào)用者調(diào)用getFiles(String)的時(shí)候如果path是空预茄，那么就拋出空指針異常(它是RuntimeException的子類),調(diào)用者不用顯示的進(jìn)行try…catch…操作進(jìn)行強(qiáng)制處理.這就要求調(diào)用者在調(diào)用這樣的方法時(shí)先進(jìn)行驗(yàn)證，避免發(fā)生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;
}

應(yīng)該選用哪種異常

通過以上的描述和舉例侦厚，可以總結(jié)出一個(gè)結(jié)論耻陕，RuntimeException異常和受檢異常之間的區(qū)別就是:是否強(qiáng)制要求調(diào)用者必須處理此異常昵慌，如果強(qiáng)制要求調(diào)用者必須進(jìn)行處理，那么就使用受檢異常淮蜈，否則就選擇非受檢異常(RuntimeException)。一般來講已卷，如果沒有特殊的要求梧田，我們建議使用RuntimeException異常。

場景介紹和技術(shù)選型

架構(gòu)描述

正如我們所知侧蘸，傳統(tǒng)的項(xiàng)目都是以MVC框架為基礎(chǔ)進(jìn)行開發(fā)的裁眯，本文主要從使用restful風(fēng)格接口的設(shè)計(jì)來體驗(yàn)一下異常處理的優(yōu)雅。
我們把關(guān)注點(diǎn)放在restful的api層(和web中的controller層類似)和service層讳癌，研究一下在service中如何拋出異常穿稳，然后api層如何進(jìn)行捕獲并且轉(zhuǎn)化異常。
使用的技術(shù)是:spring-boot,jpa(hibernate),mysql,如果對這些技術(shù)不是太熟悉晌坤，讀者需要自行閱讀相關(guān)材料逢艘。

業(yè)務(wù)場景描述

選擇一個(gè)比較簡單的業(yè)務(wù)場景，以電商中的收貨地址管理為例骤菠，用戶在移動(dòng)端進(jìn)行購買商品時(shí)它改，需要進(jìn)行收貨地址管理，在項(xiàng)目中商乎，提供一些給移動(dòng)端進(jìn)行訪問的api接口央拖，如:添加收貨地址，刪除收貨地址鹉戚，更改收貨地址鲜戒，默認(rèn)收貨地址設(shè)置，收貨地址列表查詢抹凳，單個(gè)收貨地址查詢等接口遏餐。

構(gòu)建約束條件

ok，這個(gè)是設(shè)置好的一個(gè)很基本的業(yè)務(wù)場景却桶，當(dāng)然境输，無論什么樣的api操作，其中都包含一些規(guī)則:

• 添加收貨地址:
  入?yún)?

  1. 用戶id

  2. 收貨地址實(shí)體信息

     ---

     約束:

  3. 用戶id不能為空颖系，且此用戶確實(shí)是存在 的

  4. 收貨地址的必要字段不能為 空

  5. 如果用戶還沒有收貨地址嗅剖，當(dāng)此收貨地址創(chuàng)建時(shí)設(shè)置成默認(rèn)收貨地址 —

• 刪除收貨地址:
  入?yún)?

  1. 用戶id
  2. 收貨地址id

  ---

  約束:

  1. 用戶id不能為空，且此用戶確實(shí)是存在的

  2. 收貨地址不能為空嘁扼，且此收貨地址確實(shí)是存在的

     1. 判斷此收貨地址是否是用戶的收貨地址
     2. 判斷此收貨地址是否為默認(rèn)收貨地址信粮，如果是默認(rèn)收貨地址，那么不能進(jìn)行刪除

     ---

• 更改收貨地址:
  入?yún)?

  1. 用戶id

     1. 收貨地址id

     ---

     約束:

     1. 用戶id不能為空趁啸，且此用戶確實(shí)是存在的

  2. 收貨地址不能為空强缘，且此收貨地址確實(shí)是存在的

  3. 判斷此收貨地址是否是用戶的收貨地址

     ---

• 默認(rèn)地址設(shè)置:
  入?yún)?

  1. 用戶id
  2. 收貨地址id

  ---

  約束:

  1. 用戶id不能為空督惰，且此用戶確實(shí)是存在的
     1. 收貨地址不能為空，且此收貨地址確實(shí)是存在的
     2. 判斷此收貨地址是否是用戶的收貨地址

  ---

• 收貨地址列表查詢:
  入?yún)?

  1. 用戶id

     ---

     約束:

  2. 用戶id不能為空旅掂，且此用戶確實(shí)是存在的

     ---

• 單個(gè)收貨地址查詢:
  入?yún)?

  1. 用戶id

     1. 收貨地址id

     ---

     約束:

     1. 用戶id不能為空赏胚，且此用戶確實(shí)是存在的

  2. 收貨地址不能為空，且此收貨地址確實(shí)是存在的

  3. 判斷此收貨地址是否是用戶的收貨地址

     ---

約束判斷和技術(shù)選型

對于上述列出的約束條件和功能列表商虐，我選擇幾個(gè)比較典型的異常處理場景進(jìn)行分析:添加收貨地址觉阅，刪除收貨地址，獲取收貨地址列表秘车。
那么應(yīng)該有哪些必要的知識儲備呢典勇，讓我們看一下收貨地址這個(gè)功能:
添加收貨地址中需要對用戶id和收貨地址實(shí)體信息就行校驗(yàn)，那么對于非空的判斷叮趴，我們?nèi)绾芜M(jìn)行工具的選擇呢割笙？傳統(tǒng)的判斷如下:

/**
 * 添加地址
 * @param uid
 * @param address
 * @return
 */
public Address addAddress(Integer uid,Address address){
    if(null != uid){
        //進(jìn)行處理..
    }
    return null;
}

上邊的例子，如果只判斷uid為空還好眯亦，如果再去判斷address這個(gè)實(shí)體中的某些必要屬性是否為空伤溉，在字段很多的情況下，這無非是災(zāi)難性的妻率。
那我們應(yīng)該怎么進(jìn)行這些入?yún)⒌呐袛嗄靥富穑o大家介紹兩個(gè)知識點(diǎn):

1. Guava中的Preconditions類實(shí)現(xiàn)了很多入?yún)⒎椒ǖ呐袛?/li>
2. jsr 303的validation規(guī)范(目前實(shí)現(xiàn)比較全的是hibernate實(shí)現(xiàn)的hibernate-validator)
   如果使用了這兩種推薦技術(shù)，那么入?yún)⒌呐袛鄷?huì)變得簡單很多舌涨。推薦大家多使用這些成熟的技術(shù)和jar工具包糯耍，他可以減少很多不必要的工作量。我們只需要把重心放到業(yè)務(wù)邏輯上囊嘉。而不會(huì)因?yàn)檫@些入?yún)⒌呐袛嗟⒄`更多的時(shí)間温技。

如何優(yōu)雅的設(shè)計(jì)java異常

domain介紹

根據(jù)項(xiàng)目場景來看，需要兩個(gè)domain模型扭粱，一個(gè)是用戶實(shí)體舵鳞，一個(gè)是地址實(shí)體.
Address domain如下:

@Entity
@Data
public class Address {
    @Id
    @GeneratedValue
    private Integer id;
    private String province;//省
    private String city;//市
    private String county;//區(qū)
    private Boolean isDefault;//是否是默認(rèn)地址

    @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,上邊是一個(gè)模型關(guān)系，用戶-收貨地址的關(guān)系是1-n的關(guān)系琢蛤。上邊的@Data是使用了一個(gè)叫做lombok的工具蜓堕，它自動(dòng)生成了Setter和Getter等方法，用起來非常方便博其，感興趣的讀者可以自行了解一下套才。

dao介紹

數(shù)據(jù)連接層，我們使用了spring-data-jpa這個(gè)框架慕淡，它要求我們只需要繼承框架提供的接口背伴，并且按照約定對方法進(jìn)行取名，就可以完成我們想要的數(shù)據(jù)庫操作。
用戶數(shù)據(jù)庫操作如下:

@Repository
public interface IUserDao extends JpaRepository<User,Integer> {

}

收貨地址操作如下:

@Repository
public interface IAddressDao extends JpaRepository<Address,Integer> {

}

正如讀者所看到的傻寂，我們的DAO只需要繼承JpaRepository,它就已經(jīng)幫我們完成了基本的CURD等操作息尺，如果想了解更多關(guān)于spring-data的這個(gè)項(xiàng)目，請參考一下spring的官方文檔疾掰，它比不方案我們對異常的研究搂誉。

Service異常設(shè)計(jì)

ok，終于到了我們的重點(diǎn)了静檬，我們要完成service一些的部分操作:添加收貨地址勒葱，刪除收貨地址，獲取收貨地址列表.
首先看我的service接口定義:

public interface IAddressService {

/**
 * 創(chuàng)建收貨地址
 * @param uid
 * @param address
 * @return
 */
Address createAddress(Integer uid,Address address);

/**
 * 刪除收貨地址
 * @param uid
 * @param aid
 */
void deleteAddress(Integer uid,Integer aid);

/**
 * 查詢用戶的所有收貨地址
 * @param uid
 * @return
 */
List<Address> listAddresses(Integer uid);
}

我們來關(guān)注一下實(shí)現(xiàn):

添加收貨地址

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

入?yún)?

1. 用戶id
2. 收貨地址實(shí)體信息

約束:

1. 用戶id不能為空巴柿，且此用戶確實(shí)是存在的
2. 收貨地址的必要字段不能為空
3. 如果用戶還沒有收貨地址，當(dāng)此收貨地址創(chuàng)建時(shí)設(shè)置成默認(rèn)收貨地址

先看以下代碼實(shí)現(xiàn):

 @Override
public Address createAddress(Integer uid, Address address) {
    //============ 以下為約束條件   ==============
    //1.用戶id不能為空死遭，且此用戶確實(shí)是存在的
    Preconditions.checkNotNull(uid);
    User user = userDao.findOne(uid);
    if(null == user){
        throw new RuntimeException("找不到當(dāng)前用戶!");
    }
    //2.收貨地址的必要字段不能為空
    BeanValidators.validateWithException(validator, address);
    //3.如果用戶還沒有收貨地址广恢，當(dāng)此收貨地址創(chuàng)建時(shí)設(shè)置成默認(rèn)收貨地址
    if(ObjectUtils.isEmpty(user.getAddresses())){
        address.setIsDefault(true);
    }

    //============ 以下為正常執(zhí)行的業(yè)務(wù)邏輯   ==============
    address.setUser(user);
    Address result = addressDao.save(address);
    return result;
}

其中，已經(jīng)完成了上述所描述的三點(diǎn)約束條件呀潭，當(dāng)三點(diǎn)約束條件都滿足時(shí)钉迷，才可以進(jìn)行正常的業(yè)務(wù)邏輯，否則將拋出異常(一般在此處建議拋出運(yùn)行時(shí)異常-RuntimeException)钠署。

介紹以下以上我所用到的技術(shù):

1. Preconfitions.checkNotNull(T t)這個(gè)是使用Guava中的com.google.common.base.Preconditions進(jìn)行判斷的糠聪，因?yàn)閟ervice中用到的驗(yàn)證較多，所以建議將Preconfitions改成靜態(tài)導(dǎo)入的方式:

   import static com.google.common.base.Preconditions.checkNotNull;    
   
   

   當(dāng)然Guava的github中的說明也建議我們這樣使用谐鼎。

2. BeanValidators.validateWithException(validator, address);
   這個(gè)使用了hibernate實(shí)現(xiàn)的jsr 303規(guī)范來做的舰蟆，需要傳入一個(gè)validator和一個(gè)需要驗(yàn)證的實(shí)體,那么validator是如何獲取的呢,如下:

   @Configuration
   public class BeanConfigs {

   @Bean
   public javax.validation.Validator getValidator(){
       return new LocalValidatorFactoryBean();
   }
   
   

   }

他將獲取一個(gè)Validator對象，然后我們在service中進(jìn)行注入便可以使用了:

 @Autowired     
private Validator validator ;

那么BeanValidators這個(gè)類是如何實(shí)現(xiàn)的狸棍？其實(shí)實(shí)現(xiàn)方式很簡單身害，只要去判斷jsr 303的標(biāo)注注解就ok了。
那么jsr 303的注解寫在哪里了呢草戈？當(dāng)然是寫在address實(shí)體類中了:

@Entity
@Setter
@Getter
public class Address {
@Id
    @GeneratedValue
    private Integer id;
    @NotNull
private String province;//省
@NotNull
private String city;//市
@NotNull
private String county;//區(qū)
private Boolean isDefault = false;//是否是默認(rèn)地址

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

寫好你需要的約束條件來進(jìn)行判斷塌鸯，如果合理的話，才可以進(jìn)行業(yè)務(wù)操作唐片，從而對數(shù)據(jù)庫進(jìn)行操作丙猬。
這塊的驗(yàn)證是必須的，一個(gè)最主要的原因是:這樣的驗(yàn)證可以避免臟數(shù)據(jù)的插入费韭。如果讀者有正式上線的經(jīng)驗(yàn)的話茧球，就可以理解這樣的一個(gè)事情，任何的代碼錯(cuò)誤都可以容忍和修改星持，但是如果出現(xiàn)了臟數(shù)據(jù)問題袜腥，那么它有可能是一個(gè)毀滅性的災(zāi)難。程序的問題可以修改，但是臟數(shù)據(jù)的出現(xiàn)有可能無法恢復(fù)羹令。所以這就是為什么在service中一定要判斷好約束條件鲤屡，再進(jìn)行業(yè)務(wù)邏輯操作的原因了。

1. 此處的判斷為業(yè)務(wù)邏輯判斷福侈，是從業(yè)務(wù)角度來進(jìn)行篩選判斷的酒来，除此之外，有可能在很多場景中都會(huì)有不同的業(yè)務(wù)條件約束肪凛，只需要按照要求來做就好堰汉。

對于約束條件的總結(jié)如下:

• 基本判斷約束(null值等基本判斷)
• 實(shí)體屬性約束(滿足jsr 303等基礎(chǔ)判斷)
• 業(yè)務(wù)條件約束(需求提出的不同的業(yè)務(wù)約束)

當(dāng)這個(gè)三點(diǎn)都滿足時(shí)，才可以進(jìn)行下一步操作

ok,基本介紹了如何做一個(gè)基礎(chǔ)的判斷伟墙，那么再回到異常的設(shè)計(jì)問題上翘鸭，上述代碼已經(jīng)很清楚的描述如何在適當(dāng)?shù)奈恢煤侠淼呐袛嘁粋€(gè)異常了，那么如何合理的拋出異常呢戳葵？
只拋出RuntimeException就算是優(yōu)雅的拋出異常嗎就乓？當(dāng)然不是，對于service中的拋出異常拱烁，筆者認(rèn)為大致有兩種拋出的方法:

1. 拋出帶狀態(tài)碼RumtimeException異常
2. 拋出指定類型的RuntimeException異常

相對這兩種異常的方式進(jìn)行結(jié)束生蚁，第一種異常指的是我所有的異常都拋RuntimeException異常，但是需要帶一個(gè)狀態(tài)碼戏自，調(diào)用者可以根據(jù)狀態(tài)碼再去查詢究竟service拋出了一個(gè)什么樣的異常邦投。
第二種異常是指在service中拋出什么樣的異常就自定義一個(gè)指定的異常錯(cuò)誤，然后在進(jìn)行拋出異常擅笔。
一般來講志衣，如果系統(tǒng)沒有別的特殊需求的時(shí)候，在開發(fā)設(shè)計(jì)中猛们，建議使用第二種方式蠢涝。但是比如說像基礎(chǔ)判斷的異常，就可以完全使用guava給我們提供的類庫進(jìn)行操作阅懦。jsr 303異常也可以使用自己封裝好的異常判斷類進(jìn)行操作和二，因?yàn)檫@兩種異常都是屬于基礎(chǔ)判斷，不需要為它們指定特殊的異常耳胎。但是對于第三點(diǎn)義務(wù)條件約束判斷拋出的異常惯吕，就需要拋出指定類型的異常了。
對于

throw new RuntimeException("找不到當(dāng)前用戶!");

定義一個(gè)特定的異常類來進(jìn)行這個(gè)義務(wù)異常的判斷:

public class NotFindUserException extends RuntimeException {
public NotFindUserException() {
    super("找不到此用戶");
}

public NotFindUserException(String message) {
    super(message);
}
}

然后將此處改為:

throw new NotFindUserException("找不到當(dāng)前用戶!");

or

throw new NotFindUserException();

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

@Override
public Address createAddress(Integer uid, Address address) {
    //============ 以下為約束條件   ==============
    //1.用戶id不能為空废登，且此用戶確實(shí)是存在的
    checkNotNull(uid);
    User user = userDao.findOne(uid);
    if(null == user){
        throw new NotFindUserException("找不到當(dāng)前用戶!");
    }
    //2.收貨地址的必要字段不能為空
    BeanValidators.validateWithException(validator, address);
    //3.如果用戶還沒有收貨地址，當(dāng)此收貨地址創(chuàng)建時(shí)設(shè)置成默認(rèn)收貨地址
    if(ObjectUtils.isEmpty(user.getAddresses())){
        address.setIsDefault(true);
    }

    //============ 以下為正常執(zhí)行的業(yè)務(wù)邏輯   ==============
    address.setUser(user);
    Address result = addressDao.save(address);
    return result;
}

這樣的service就看起來穩(wěn)定性和理解性就比較強(qiáng)了郁惜。

刪除收貨地址:

入?yún)?

1. 用戶id
2. 收貨地址id

約束:

1. 用戶id不能為空堡距，且此用戶確實(shí)是存在的
2. 收貨地址不能為空，且此收貨地址確實(shí)是存在的
3. 判斷此收貨地址是否是用戶的收貨地址
4. 判斷此收貨地址是否為默認(rèn)收貨地址，如果是默認(rèn)收貨地址羽戒，那么不能進(jìn)行刪除

它與上述添加收貨地址類似缤沦，故不再贅述，delete的service設(shè)計(jì)如下:

@Override
public void deleteAddress(Integer uid, Integer aid) {
    //============ 以下為約束條件   ==============
    //1.用戶id不能為空易稠，且此用戶確實(shí)是存在的
    checkNotNull(uid);
    User user = userDao.findOne(uid);
    if(null == user){
        throw new NotFindUserException();
    }
    //2.收貨地址不能為空缸废，且此收貨地址確實(shí)是存在的
    checkNotNull(aid);
    Address address = addressDao.findOne(aid);
    if(null == address){
        throw new NotFindAddressException();
    }
    //3.判斷此收貨地址是否是用戶的收貨地址
    if(!address.getUser().equals(user)){
        throw new NotMatchUserAddressException();
    }
    //4.判斷此收貨地址是否為默認(rèn)收貨地址，如果是默認(rèn)收貨地址驶社，那么不能進(jìn)行刪除
    if(address.getIsDefault()){
       throw  new DefaultAddressNotDeleteException();
    }

    //============ 以下為正常執(zhí)行的業(yè)務(wù)邏輯   ==============
    addressDao.delete(address);
}

設(shè)計(jì)了相關(guān)的四個(gè)異常類:NotFindUserException,NotFindAddressException,NotMatchUserAddressException,DefaultAddressNotDeleteException.根據(jù)不同的業(yè)務(wù)需求拋出不同的異常企量。

獲取收貨地址列表:

入?yún)?

1. 用戶id

約束:

1. 用戶id不能為空，且此用戶確實(shí)是存在的

代碼如下:

 @Override
public List<Address> listAddresses(Integer uid) {
    //============ 以下為約束條件   ==============
    //1.用戶id不能為空亡电，且此用戶確實(shí)是存在的
    checkNotNull(uid);
    User user = userDao.findOne(uid);
    if(null == user){
        throw new NotFindUserException();
    }

    //============ 以下為正常執(zhí)行的業(yè)務(wù)邏輯   ==============
    User result = userDao.findOne(uid);
    return result.getAddresses();
}

api異常設(shè)計(jì)

大致有兩種拋出的方法:

1. 拋出帶狀態(tài)碼RumtimeException異常
2. 拋出指定類型的RuntimeException異常

這個(gè)是在設(shè)計(jì)service層異常時(shí)提到的届巩，通過對service層的介紹，我們在service層拋出異常時(shí)選擇了第二種拋出的方式份乒，不同的是恕汇，在api層拋出異常我們需要使用這兩種方式進(jìn)行拋出:要指定api異常的類型，并且要指定相關(guān)的狀態(tài)碼冒嫡，然后才將異常拋出，這種異常設(shè)計(jì)的核心是讓調(diào)用api的使用者更能清楚的了解發(fā)生異常的詳細(xì)信息四苇，除了拋出異常外孝凌，我們還需要將狀態(tài)碼對應(yīng)的異常詳細(xì)信息以及異常有可能發(fā)生的問題制作成一個(gè)對應(yīng)的表展示給用戶，方便用戶的查詢月腋。（如github提供的api文檔蟀架，微信提供的api文檔等）,還有一個(gè)好處:如果用戶需要自定義提示消息，可以根據(jù)返回的狀態(tài)碼進(jìn)行提示的修改榆骚。

api驗(yàn)證約束

首先對于api的設(shè)計(jì)來說片拍，需要存在一個(gè)dto對象，這個(gè)對象負(fù)責(zé)和調(diào)用者進(jìn)行數(shù)據(jù)的溝通和傳遞妓肢，然后dto->domain在傳給service進(jìn)行操作捌省，這一點(diǎn)一定要注意，第二點(diǎn)碉钠，除了說道的service需要進(jìn)行基礎(chǔ)判斷(null判斷)和jsr 303驗(yàn)證以外纲缓，同樣的，api層也需要進(jìn)行相關(guān)的驗(yàn)證喊废，如果驗(yàn)證不通過的話祝高，直接返回給調(diào)用者，告知調(diào)用失敗污筷，不應(yīng)該帶著不合法的數(shù)據(jù)再進(jìn)行對service的訪問工闺，那么讀者可能會(huì)有些迷惑，不是service已經(jīng)進(jìn)行驗(yàn)證了，為什么api層還需要進(jìn)行驗(yàn)證么陆蟆？這里便設(shè)計(jì)到了一個(gè)概念:編程中的墨菲定律雷厂，如果api層的數(shù)據(jù)驗(yàn)證疏忽了，那么有可能不合法數(shù)據(jù)就帶到了service層遍搞，進(jìn)而講臟數(shù)據(jù)保存到了數(shù)據(jù)庫罗侯。

所以縝密編程的核心是:永遠(yuǎn)不要相信收到的數(shù)據(jù)是合法的。

api異常設(shè)計(jì)

設(shè)計(jì)api層異常時(shí)溪猿，正如我們上邊所說的钩杰，需要提供錯(cuò)誤碼和錯(cuò)誤信息，那么可以這樣設(shè)計(jì)诊县，提供一個(gè)通用的api超類異常讲弄，其他不同的api異常都繼承自這個(gè)超類:

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。
以默認(rèn)地址不能刪除為例:

public class ApiDefaultAddressNotDeleteException extends ApiException {

public ApiDefaultAddressNotDeleteException(String message) {
    super(AddressErrorCode.DefaultAddressNotDeleteErrorCode, message, null);
}

}

AddressErrorCode.DefaultAddressNotDeleteErrorCode就是需要提供給調(diào)用者的錯(cuò)誤碼依痊。錯(cuò)誤碼類如下:

public abstract class AddressErrorCode {
    public static final Long DefaultAddressNotDeleteErrorCode = 10001L;//默認(rèn)地址不能刪除
    public static final Long NotFindAddressErrorCode = 10002L;//找不到此收貨地址
    public static final Long NotFindUserErrorCode = 10003L;//找不到此用戶
    public static final Long NotMatchUserAddressErrorCode = 10004L;//用戶與收貨地址不匹配
}

ok,那么api層的異常就已經(jīng)設(shè)計(jì)完了避除，在此多說一句，AddressErrorCode錯(cuò)誤碼類存放了可能出現(xiàn)的錯(cuò)誤碼胸嘁，更合理的做法是把他放到配置文件中進(jìn)行管理瓶摆。

api處理異常

api層會(huì)調(diào)用service層，然后來處理service中出現(xiàn)的所有異常性宏，首先群井，需要保證一點(diǎn)，一定要讓api層非常輕毫胜，基本上做成一個(gè)轉(zhuǎn)發(fā)的功能就好(接口參數(shù)书斜，傳遞給service參數(shù)，返回給調(diào)用者數(shù)據(jù),這三個(gè)基本功能)酵使，然后就要在傳遞給service參數(shù)的那個(gè)方法調(diào)用上進(jìn)行異常處理荐吉。

此處僅以添加地址為例:

 @Autowired
private IAddressService addressService;

/**
 * 添加收貨地址
 * @param addressDTO
 * @return
 */
@RequestMapping(method = RequestMethod.POST)
public AddressDTO add(@Valid @RequestBody AddressDTO addressDTO){
    Address address = new Address();
    BeanUtils.copyProperties(addressDTO,address);
    Address result;
    try {
        result = addressService.createAddress(addressDTO.getUid(), address);
    }catch (NotFindUserException e){
        throw new ApiNotFindUserException("找不到該用戶");
    }catch (Exception e){//未知錯(cuò)誤
        throw new ApiException(e);
    }
    AddressDTO resultDTO = new AddressDTO();
    BeanUtils.copyProperties(result,resultDTO);
    resultDTO.setUid(result.getUser().getId());

    return resultDTO;
}

這里的處理方案是調(diào)用service時(shí)，判斷異常的類型口渔，然后將任何service異常都轉(zhuǎn)化成api異常样屠，然后拋出api異常，這是常用的一種異常轉(zhuǎn)化方式缺脉。相似刪除收貨地址和獲取收貨地址也類似這樣處理瞧哟，在此，不在贅述枪向。

api異常轉(zhuǎn)化

已經(jīng)講解了如何拋出異常和何如將service異常轉(zhuǎn)化為api異常勤揩，那么轉(zhuǎn)化成api異常直接拋出是否就完成了異常處理呢？ 答案是否定的秘蛔，當(dāng)拋出api異常后陨亡，我們需要把a(bǔ)pi異常返回的數(shù)據(jù)(json or xml)讓用戶看懂傍衡，那么需要把a(bǔ)pi異常轉(zhuǎn)化成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異常轉(zhuǎn)化成用戶可以讀懂的DTO對象了，代碼中用到了@ControllerAdvice负蠕，這是spring MVC提供的一個(gè)特殊的切面處理蛙埂。

當(dāng)調(diào)用api接口發(fā)生異常時(shí)，用戶也可以收到正常的數(shù)據(jù)格式了,比如當(dāng)沒有用戶(uid為2)時(shí)遮糖，卻為這個(gè)用戶添加收貨地址,postman(Google plugin 用于模擬http請求)之后的數(shù)據(jù):

{
  "errorCode": 10003,
  "tip": "找不到該用戶"
}

總結(jié)

本文只從如何設(shè)計(jì)異常作為重點(diǎn)來講解绣的，涉及到的api傳輸和service的處理，還有待優(yōu)化欲账，比如api接口訪問需要使用https進(jìn)行加密屡江，api接口需要OAuth2.0授權(quán)或api接口需要簽名認(rèn)證等問題，文中都未曾提到赛不，本文的重心在于異常如何處理惩嘉，所以讀者只需關(guān)注涉及到異常相關(guān)的問題和處理方式就可以了。希望本篇文章對你理解異常有所幫助踢故。

原文