導(dǎo)語(yǔ)

異常處理是程序開(kāi)發(fā)中必不可少操作之一丽声，但如何正確優(yōu)雅的對(duì)異常進(jìn)行處理確是一門(mén)學(xué)問(wèn)，筆者根據(jù)自己的開(kāi)發(fā)經(jīng)驗(yàn)來(lái)談一談我是如何對(duì)異常進(jìn)行處理的崇呵。

由于本文只作一些經(jīng)驗(yàn)之談豆挽，不涉及到基礎(chǔ)知識(shí)部分蛮瞄，如果讀者對(duì)異常的概念還很模糊磕蛇，請(qǐng)先查看基礎(chǔ)知識(shí)。

如何選擇異常類(lèi)型

異常的類(lèi)別

正如我們所知道的膛檀，java中的異常的超類(lèi)是java.lang.Throwable(后文省略為T(mén)hrowable),它有兩個(gè)比較重要的子類(lèi),java.lang.Exception(后文省略為Exception)和java.lang.Error(后文省略為Error)馅扣，其中Error由JVM虛擬機(jī)進(jìn)行管理,如我們所熟知的OutOfMemoryError異常等斟赚，所以我們本文不關(guān)注Error異常，那么我們細(xì)說(shuō)一下Exception異常差油。

Exception異常有個(gè)比較重要的子類(lèi)拗军，叫做RuntimeException。我們將RuntimeException或其他繼承自RuntimeException的子類(lèi)稱(chēng)為非受檢異常(unchecked Exception)蓄喇，其他繼承自Exception異常的子類(lèi)稱(chēng)為受檢異常(checked Exception)发侵。本文重點(diǎn)來(lái)關(guān)注一下受檢異常和非受檢異常這兩種異常。

如何選擇異常

從筆者的開(kāi)發(fā)經(jīng)驗(yàn)來(lái)看妆偏，如果在一個(gè)應(yīng)用中刃鳄，需要開(kāi)發(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)行處理步责，相似的，如果在寫(xiě)某個(gè)方法時(shí)禀苦，你認(rèn)為這是個(gè)偶然異常蔓肯，理論上說(shuō)，你覺(jué)得運(yùn)行時(shí)可能會(huì)碰到什么問(wèn)題伦忠，而這些問(wèn)題也許不是必然發(fā)生的省核，也不需要調(diào)用者顯示的通過(guò)異常來(lái)判斷業(yè)務(wù)流程操作的，那么這時(shí)就可以使用一個(gè)RuntimeException這樣的非受檢異常.

好了昆码，估計(jì)我上邊說(shuō)的這段話(huà)气忠，你讀了很多遍也依然覺(jué)得晦澀了。

那么赋咽，請(qǐng)跟著我的思路旧噪，在慢慢領(lǐng)會(huì)一下。

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

首先我們需要了解一個(gè)問(wèn)題脓匿，什么時(shí)候才需要拋異常淘钟？異常的設(shè)計(jì)是方便給開(kāi)發(fā)者使用的，但不是亂用的陪毡，筆者對(duì)于什么時(shí)候拋異常這個(gè)問(wèn)題也問(wèn)了很多朋友米母，能給出準(zhǔn)確答案的確實(shí)不多勾扭。其實(shí)這個(gè)問(wèn)題很簡(jiǎn)單，如果你覺(jué)得某些”問(wèn)題”解決不了了铁瞒，那么你就可以?huà)伋霎惓Ａ嗣钌１热纾阍趯?xiě)一個(gè)service,其中在寫(xiě)到某段代碼處,你發(fā)現(xiàn)可能會(huì)產(chǎn)生問(wèn)題慧耍，那么就請(qǐng)拋出異常吧身辨，相信我，你此時(shí)拋出異常將是一個(gè)最佳時(shí)機(jī)芍碧。

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

了解完了什么時(shí)候才需要拋出異常后煌珊，我們?cè)偎伎家粋€(gè)問(wèn)題，真的當(dāng)我們拋出異常時(shí)泌豆，我們應(yīng)該選用怎樣的異常呢定庵？究竟是受檢異常還是非受檢異常呢(RuntimeException)呢？我來(lái)舉例說(shuō)明一下這個(gè)問(wèn)題践美，先從受檢異常說(shuō)起,比如說(shuō)有這樣一個(gè)業(yè)務(wù)邏輯洗贰，需要從某文件中讀取某個(gè)數(shù)據(jù)，這個(gè)讀取操作可能是由于文件被刪除等其他問(wèn)題導(dǎo)致無(wú)法獲取從而出現(xiàn)讀取錯(cuò)誤陨倡，那么就要從redis或mysql數(shù)據(jù)庫(kù)中再去獲取此數(shù)據(jù),參考如下代碼敛滋，getKey(Integer)為入口程序.

public String getKey(Integer key){

? ? String? value;

? ? try {

? ? ? ? InputStream inputStream = getFiles("/file/nofile");

? ? ? ? //接下來(lái)從流中讀取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，看了以上代碼以后兴革，你也許心中有一些想法绎晃，原來(lái)受檢異常可以控制義務(wù)邏輯杂曲，對(duì)庶艾，沒(méi)錯(cuò)，通過(guò)受檢異常真的可以控制業(yè)務(wù)邏輯擎勘，但是切記不要這樣使用咱揍，我們應(yīng)該合理的拋出異常，因?yàn)槌绦虮旧聿攀橇鞒膛锒惓５淖饔脙H僅是當(dāng)你進(jìn)行不下去的時(shí)候找到的一個(gè)借口而已煤裙，它并不能當(dāng)成控制程序流程的入口或出口，如果這樣使用的話(huà)噪漾，是在將異常的作用擴(kuò)大化硼砰，這樣將會(huì)導(dǎo)致代碼復(fù)雜程度的增加，耦合性會(huì)提高欣硼，代碼可讀性降低等問(wèn)題题翰。那么就一定不要使用這樣的異常嗎？其實(shí)也不是，在真的有這樣的需求的時(shí)候豹障，我們可以這樣使用冯事，只是切記，不要把它真的當(dāng)成控制流程的工具或手段血公。那么究竟什么時(shí)候才要拋出這樣的異常呢桅咆？要考慮，如果調(diào)用者調(diào)用出錯(cuò)后坞笙，一定要讓調(diào)用者對(duì)此錯(cuò)誤進(jìn)行處理才可以，滿(mǎn)足這樣的要求時(shí)荚虚，我們才會(huì)考慮使用受檢異常薛夜。

接下來(lái)，我們來(lái)看一下非受檢異常呢(RuntimeException)版述，對(duì)于RuntimeException這種異常梯澜，我們其實(shí)很多見(jiàn)，比如java.lang.NullPointerException／java.lang.IllegalArgumentException等渴析，那么這種異常我們時(shí)候拋出呢晚伙？當(dāng)我們?cè)趯?xiě)某個(gè)方法的時(shí)候，可能會(huì)偶然遇到某個(gè)錯(cuò)誤俭茧，我們認(rèn)為這個(gè)問(wèn)題時(shí)運(yùn)行時(shí)可能為發(fā)生的咆疗，并且理論上講，沒(méi)有這個(gè)問(wèn)題的話(huà)母债，程序?qū)?huì)正常執(zhí)行的時(shí)候午磁，它不強(qiáng)制要求調(diào)用者一定要捕獲這個(gè)異常，此時(shí)拋出RuntimeException異常,舉個(gè)例子毡们，當(dāng)傳來(lái)一個(gè)路徑的時(shí)候迅皇，需要返回一個(gè)路徑對(duì)應(yīng)的File對(duì)象:

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的子類(lèi)),調(diào)用者不用顯示的進(jìn)行try…catch…操作進(jìn)行強(qiáng)制處理.這就要求調(diào)用者在調(diào)用這樣的方法時(shí)先進(jìn)行驗(yàn)證登颓，避免發(fā)生RuntimeException.如下:

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

通過(guò)以上的描述和舉例，可以總結(jié)出一個(gè)結(jié)論红氯，RuntimeException異常和受檢異常之間的區(qū)別就是:是否強(qiáng)制要求調(diào)用者必須處理此異常框咙，如果強(qiáng)制要求調(diào)用者必須進(jìn)行處理，那么就使用受檢異常脖隶，否則就選擇非受檢異常(RuntimeException)扁耐。一般來(lái)講，如果沒(méi)有特殊的要求产阱，我們建議使用RuntimeException異常婉称。

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

架構(gòu)描述

正如我們所知，傳統(tǒng)的項(xiàng)目都是以MVC框架為基礎(chǔ)進(jìn)行開(kāi)發(fā)的，本文主要從使用restful風(fēng)格接口的設(shè)計(jì)來(lái)體驗(yàn)一下異常處理的優(yōu)雅王暗。

我們把關(guān)注點(diǎn)放在restful的api層(和web中的controller層類(lèi)似)和service層悔据，研究一下在service中如何拋出異常，然后api層如何進(jìn)行捕獲并且轉(zhuǎn)化異常俗壹。

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

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

選擇一個(gè)比較簡(jiǎn)單的業(yè)務(wù)場(chǎng)景绷雏，以電商中的收貨地址管理為例头滔，用戶(hù)在移動(dòng)端進(jìn)行購(gòu)買(mǎi)商品時(shí)，需要進(jìn)行收貨地址管理涎显，在項(xiàng)目中坤检，提供一些給移動(dòng)端進(jìn)行訪(fǎng)問(wèn)的api接口，如:添加收貨地址期吓，刪除收貨地址早歇，更改收貨地址，默認(rèn)收貨地址設(shè)置讨勤，收貨地址列表查詢(xún)箭跳，單個(gè)收貨地址查詢(xún)等接口。

構(gòu)建約束條件

ok潭千，這個(gè)是設(shè)置好的一個(gè)很基本的業(yè)務(wù)場(chǎng)景谱姓，當(dāng)然，無(wú)論什么樣的api操作脊岳，其中都包含一些規(guī)則:

添加收貨地址:

入?yún)?

? ? 用戶(hù)id

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

約束:

? ? 用戶(hù)id不能為空逝段，且此用戶(hù)確實(shí)是存在 的

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

? ? 如果用戶(hù)還沒(méi)有收貨地址，當(dāng)此收貨地址創(chuàng)建時(shí)設(shè)置成默認(rèn)收貨地址 —

刪除收貨地址:

入?yún)?

? ? 用戶(hù)id

? ? 收貨地址id

約束:

? ? 用戶(hù)id不能為空割捅，且此用戶(hù)確實(shí)是存在的

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

? ? 判斷此收貨地址是否是用戶(hù)的收貨地址

? ? 判斷此收貨地址是否為默認(rèn)收貨地址，如果是默認(rèn)收貨地址亿驾，那么不能進(jìn)行刪除

更改收貨地址:

入?yún)?

? ? 用戶(hù)id

? ? 收貨地址id

約束:

? ? 用戶(hù)id不能為空嘹黔，且此用戶(hù)確實(shí)是存在的

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

? ? 判斷此收貨地址是否是用戶(hù)的收貨地址

默認(rèn)地址設(shè)置:

入?yún)?

? ? 用戶(hù)id

? ? 收貨地址id

約束:

? ? 用戶(hù)id不能為空莫瞬，且此用戶(hù)確實(shí)是存在的

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

? ? 判斷此收貨地址是否是用戶(hù)的收貨地址

收貨地址列表查詢(xún):

入?yún)?

? ? 用戶(hù)id

約束:

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

單個(gè)收貨地址查詢(xún):

入?yún)?

? ? 用戶(hù)id

? ? 收貨地址id

約束:

? ? 用戶(hù)id不能為空疼邀，且此用戶(hù)確實(shí)是存在的

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

? ? 判斷此收貨地址是否是用戶(hù)的收貨地址

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

對(duì)于上述列出的約束條件和功能列表，我選擇幾個(gè)比較典型的異常處理場(chǎng)景進(jìn)行分析:添加收貨地址旁振，刪除收貨地址获询，獲取收貨地址列表涨岁。

那么應(yīng)該有哪些必要的知識(shí)儲(chǔ)備呢，讓我們看一下收貨地址這個(gè)功能:

添加收貨地址中需要對(duì)用戶(hù)id和收貨地址實(shí)體信息就行校驗(yàn)吉嚣，那么對(duì)于非空的判斷梢薪，我們?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í)體中的某些必要屬性是否為空，在字段很多的情況下秋泄，這無(wú)非是災(zāi)難性的琐馆。

那我們應(yīng)該怎么進(jìn)行這些入?yún)⒌呐袛嗄兀o大家介紹兩個(gè)知識(shí)點(diǎn):

Guava中的Preconditions類(lèi)實(shí)現(xiàn)了很多入?yún)⒎椒ǖ呐袛?/b>

jsr 303的validation規(guī)范(目前實(shí)現(xiàn)比較全的是hibernate實(shí)現(xiàn)的hibernate-validator)

如果使用了這兩種推薦技術(shù)恒序，那么入?yún)⒌呐袛鄷?huì)變得簡(jiǎn)單很多啡捶。推薦大家多使用這些成熟的技術(shù)和jar工具包，他可以減少很多不必要的工作量奸焙。我們只需要把重心放到業(yè)務(wù)邏輯上。而不會(huì)因?yàn)檫@些入?yún)⒌呐袛嗟⒄`更多的時(shí)間彤敛。

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

domain介紹

根據(jù)項(xiàng)目場(chǎng)景來(lái)看与帆，需要兩個(gè)domain模型，一個(gè)是用戶(hù)實(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)系玄糟，用戶(hù)-收貨地址的關(guān)系是1-n的關(guān)系。上邊的@Data是使用了一個(gè)叫做lombok的工具袄秩，它自動(dòng)生成了Setter和Getter等方法阵翎，用起來(lái)非常方便，感興趣的讀者可以自行了解一下之剧。

dao介紹

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

用戶(hù)數(shù)據(jù)庫(kù)操作如下:

@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)目，請(qǐng)參考一下spring的官方文檔帘腹，它比不方案我們對(duì)異常的研究贰盗。

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);

/**

* 查詢(xún)用戶(hù)的所有收貨地址

* @param uid

* @return

*/

List<Address> listAddresses(Integer uid);

}

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

添加收貨地址

首先再來(lái)看一下之前整理的約束條件:

入?yún)?

? ? 用戶(hù)id

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

約束:

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

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

? ? 如果用戶(hù)還沒(méi)有收貨地址书释，當(dāng)此收貨地址創(chuàng)建時(shí)設(shè)置成默認(rèn)收貨地址

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

@Override

public Address createAddress(Integer uid, Address address) {

? ? //============ 以下為約束條件? ==============

? ? //1.用戶(hù)id不能為空翘贮，且此用戶(hù)確實(shí)是存在的

? ? Preconditions.checkNotNull(uid);

? ? User user = userDao.findOne(uid);

? ? if(null == user){

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

? ? }

? ? //2.收貨地址的必要字段不能為空

? ? BeanValidators.validateWithException(validator, address);

? ? //3.如果用戶(hù)還沒(méi)有收貨地址，當(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)約束條件都滿(mǎ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中的說(shuō)明也建議我們這樣使用斋竞。

2. BeanValidators.validateWithException(validator, address);

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

@Configuration

public class BeanConfigs {

@Bean

public javax.validation.Validator getValidator(){

? ? return new LocalValidatorFactoryBean();

}

}

他將獲取一個(gè)Validator對(duì)象秃殉，然后我們?cè)趕ervice中進(jìn)行注入便可以使用了:

@Autowired? ?

private Validator validator ;

那么BeanValidators這個(gè)類(lèi)是如何實(shí)現(xiàn)的坝初？其實(shí)實(shí)現(xiàn)方式很簡(jiǎn)單，只要去判斷jsr 303的標(biāo)注注解就ok了钾军。

那么jsr 303的注解寫(xiě)在哪里了呢鳄袍？當(dāng)然是寫(xiě)在address實(shí)體類(lèi)中了:

@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;

}

寫(xiě)好你需要的約束條件來(lái)進(jìn)行判斷，如果合理的話(huà)吏恭，才可以進(jìn)行業(yè)務(wù)操作拗小，從而對(duì)數(shù)據(jù)庫(kù)進(jìn)行操作。

這塊的驗(yàn)證是必須的樱哼，一個(gè)最主要的原因是:這樣的驗(yàn)證可以避免臟數(shù)據(jù)的插入哀九。如果讀者有正式上線(xiàn)的經(jīng)驗(yàn)的話(huà)，就可以理解這樣的一個(gè)事情搅幅，任何的代碼錯(cuò)誤都可以容忍和修改阅束，但是如果出現(xiàn)了臟數(shù)據(jù)問(wèn)題，那么它有可能是一個(gè)毀滅性的災(zāi)難茄唐。程序的問(wèn)題可以修改围俘，但是臟數(shù)據(jù)的出現(xiàn)有可能無(wú)法恢復(fù)。所以這就是為什么在service中一定要判斷好約束條件琢融，再進(jìn)行業(yè)務(wù)邏輯操作的原因了界牡。

此處的判斷為業(yè)務(wù)邏輯判斷，是從業(yè)務(wù)角度來(lái)進(jìn)行篩選判斷的漾抬，除此之外宿亡，有可能在很多場(chǎng)景中都會(huì)有不同的業(yè)務(wù)條件約束，只需要按照要求來(lái)做就好纳令。

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

? ? 基本判斷約束(null值等基本判斷)

? ? 實(shí)體屬性約束(滿(mǎn)足jsr 303等基礎(chǔ)判斷)

? ? 業(yè)務(wù)條件約束(需求提出的不同的業(yè)務(wù)約束)

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

ok,基本介紹了如何做一個(gè)基礎(chǔ)的判斷克胳，那么再回到異常的設(shè)計(jì)問(wèn)題上，上述代碼已經(jīng)很清楚的描述如何在適當(dāng)?shù)奈恢煤侠淼呐袛嘁粋€(gè)異常了圈匆，那么如何合理的拋出異常呢漠另？

只拋出RuntimeException就算是優(yōu)雅的拋出異常嗎？當(dāng)然不是跃赚，對(duì)于service中的拋出異常笆搓，筆者認(rèn)為大致有兩種拋出的方法:

? ? 拋出帶狀態(tài)碼RumtimeException異常

? ? 拋出指定類(lèi)型的RuntimeException異常

相對(duì)這兩種異常的方式進(jìn)行結(jié)束，第一種異常指的是我所有的異常都拋RuntimeException異常纬傲，但是需要帶一個(gè)狀態(tài)碼满败，調(diào)用者可以根據(jù)狀態(tài)碼再去查詢(xún)究竟service拋出了一個(gè)什么樣的異常。

第二種異常是指在service中拋出什么樣的異常就自定義一個(gè)指定的異常錯(cuò)誤叹括，然后在進(jìn)行拋出異常算墨。

一般來(lái)講，如果系統(tǒng)沒(méi)有別的特殊需求的時(shí)候汁雷，在開(kāi)發(fā)設(shè)計(jì)中净嘀，建議使用第二種方式。但是比如說(shuō)像基礎(chǔ)判斷的異常侠讯，就可以完全使用guava給我們提供的類(lèi)庫(kù)進(jìn)行操作面粮。jsr 303異常也可以使用自己封裝好的異常判斷類(lèi)進(jìn)行操作，因?yàn)檫@兩種異常都是屬于基礎(chǔ)判斷继低，不需要為它們指定特殊的異常。但是對(duì)于第三點(diǎn)義務(wù)條件約束判斷拋出的異常稍走，就需要拋出指定類(lèi)型的異常了袁翁。

對(duì)于

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

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

public class NotFindUserException extends RuntimeException {

public NotFindUserException() {

? ? super("找不到此用戶(hù)");

}

public NotFindUserException(String message) {

? ? super(message);

}

}

然后將此處改為:

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

or

throw new NotFindUserException();

ok,通過(guò)以上對(duì)service層的修改，代碼更改如下:

@Override

public Address createAddress(Integer uid, Address address) {

? ? //============ 以下為約束條件? ==============

? ? //1.用戶(hù)id不能為空婿脸，且此用戶(hù)確實(shí)是存在的

? ? checkNotNull(uid);

? ? User user = userDao.findOne(uid);

? ? if(null == user){

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

? ? }

? ? //2.收貨地址的必要字段不能為空

? ? BeanValidators.validateWithException(validator, address);

? ? //3.如果用戶(hù)還沒(méi)有收貨地址粱胜，當(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就看起來(lái)穩(wěn)定性和理解性就比較強(qiáng)了。

刪除收貨地址:

入?yún)?

? ? 用戶(hù)id

? ? 收貨地址id

約束:

? ? 用戶(hù)id不能為空狐树，且此用戶(hù)確實(shí)是存在的

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

? ? 判斷此收貨地址是否是用戶(hù)的收貨地址

? ? 判斷此收貨地址是否為默認(rèn)收貨地址，如果是默認(rèn)收貨地址抑钟，那么不能進(jìn)行刪除

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

@Override

public void deleteAddress(Integer uid, Integer aid) {

? ? //============ 以下為約束條件? ==============

? ? //1.用戶(hù)id不能為空在塔，且此用戶(hù)確實(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.判斷此收貨地址是否是用戶(hù)的收貨地址

? ? 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è)異常類(lèi):NotFindUserException,NotFindAddressException,NotMatchUserAddressException,DefaultAddressNotDeleteException.根據(jù)不同的業(yè)務(wù)需求拋出不同的異常绰沥。

獲取收貨地址列表:

入?yún)?

? ? 用戶(hù)id

約束:

? ? 用戶(hù)id不能為空篱蝇，且此用戶(hù)確實(shí)是存在的

代碼如下:

@Override

public List<Address> listAddresses(Integer uid) {

? ? //============ 以下為約束條件? ==============

? ? //1.用戶(hù)id不能為空，且此用戶(hù)確實(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ì)

大致有兩種拋出的方法:

? ? 拋出帶狀態(tài)碼RumtimeException異常

? ? 拋出指定類(lèi)型的RuntimeException異常

這個(gè)是在設(shè)計(jì)service層異常時(shí)提到的徽曲，通過(guò)對(duì)service層的介紹零截，我們?cè)趕ervice層拋出異常時(shí)選擇了第二種拋出的方式，不同的是秃臣，在api層拋出異常我們需要使用這兩種方式進(jìn)行拋出:要指定api異常的類(lèi)型涧衙，并且要指定相關(guān)的狀態(tài)碼，然后才將異常拋出甜刻，這種異常設(shè)計(jì)的核心是讓調(diào)用api的使用者更能清楚的了解發(fā)生異常的詳細(xì)信息绍撞，除了拋出異常外，我們還需要將狀態(tài)碼對(duì)應(yīng)的異常詳細(xì)信息以及異常有可能發(fā)生的問(wèn)題制作成一個(gè)對(duì)應(yīng)的表展示給用戶(hù)得院，方便用戶(hù)的查詢(xún)傻铣。（如github提供的api文檔，微信提供的api文檔等）,還有一個(gè)好處:如果用戶(hù)需要自定義提示消息祥绞，可以根據(jù)返回的狀態(tài)碼進(jìn)行提示的修改非洲。

api驗(yàn)證約束

首先對(duì)于api的設(shè)計(jì)來(lái)說(shuō)，需要存在一個(gè)dto對(duì)象蜕径，這個(gè)對(duì)象負(fù)責(zé)和調(diào)用者進(jìn)行數(shù)據(jù)的溝通和傳遞两踏，然后dto->domain在傳給service進(jìn)行操作，這一點(diǎn)一定要注意兜喻，第二點(diǎn)梦染，除了說(shuō)道的service需要進(jìn)行基礎(chǔ)判斷(null判斷)和jsr 303驗(yàn)證以外，同樣的朴皆，api層也需要進(jìn)行相關(guān)的驗(yàn)證帕识，如果驗(yàn)證不通過(guò)的話(huà)，直接返回給調(diào)用者遂铡，告知調(diào)用失敗肮疗，不應(yīng)該帶著不合法的數(shù)據(jù)再進(jìn)行對(duì)service的訪(fǎng)問(wèn)，那么讀者可能會(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ù)庫(kù)宗侦。

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

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

設(shè)計(jì)api層異常時(shí)，正如我們上邊所說(shuō)的凝垛，需要提供錯(cuò)誤碼和錯(cuò)誤信息懊悯，那么可以這樣設(shè)計(jì)蜓谋，提供一個(gè)通用的api超類(lèi)異常，其他不同的api異常都繼承自這個(gè)超類(lèi):

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ò)誤碼類(lèi)如下:

public abstract class AddressErrorCode {

? ? public static final Long DefaultAddressNotDeleteErrorCode = 10001L;//默認(rèn)地址不能刪除

? ? public static final Long NotFindAddressErrorCode = 10002L;//找不到此收貨地址

? ? public static final Long NotFindUserErrorCode = 10003L;//找不到此用戶(hù)

? ? public static final Long NotMatchUserAddressErrorCode = 10004L;//用戶(hù)與收貨地址不匹配

}

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

api處理異常

api層會(huì)調(diào)用service層呀忧，然后來(lái)處理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("找不到該用戶(hù)");

? ? }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í)咐吼，判斷異常的類(lèi)型吹缔，然后將任何service異常都轉(zhuǎn)化成api異常，然后拋出api異常锯茄，這是常用的一種異常轉(zhuǎn)化方式厢塘。相似刪除收貨地址和獲取收貨地址也類(lèi)似這樣處理，在此肌幽，不在贅述晚碾。

api異常轉(zhuǎn)化

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

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

{

? "errorCode": 10003,

? "tip": "找不到該用戶(hù)"

}

總結(jié)

本文只從如何設(shè)計(jì)異常作為重點(diǎn)來(lái)講解步氏，涉及到的api傳輸和service的處理，還有待優(yōu)化徒爹，比如api接口訪(fǎng)問(wèn)需要使用https進(jìn)行加密荚醒，api接口需要OAuth2.0授權(quán)或api接口需要簽名認(rèn)證等問(wèn)題芋类，文中都未曾提到，本文的重心在于異常如何處理界阁，所以讀者只需關(guān)注涉及到異常相關(guān)的問(wèn)題和處理方式就可以了侯繁。希望本篇文章對(duì)你理解異常有所幫助。

本文來(lái)源：Lrwin

lrwinx.github.io/2016/04/28/如何優(yōu)雅的設(shè)計(jì)java異常/