點擊上方藍色字體，選擇“設(shè)為星標(biāo)”

回復(fù)”666“獲取面試寶典

異常處理是程序開發(fā)中必不可少操作之一，但如何正確優(yōu)雅的對異常進行處理確是一門學(xué)問，筆者根據(jù)自己的開發(fā)經(jīng)驗來談一談我是如何對異常進行處理的。

由于本文只作一些經(jīng)驗之談，不涉及到基礎(chǔ)知識部分，如果讀者對異常的概念還很模糊，請先查看基礎(chǔ)知識。

如何選擇異常類型

異常的類別

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

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

如何選擇異常

從筆者的開發(fā)經(jīng)驗來看，如果在一個應(yīng)用中，需要開發(fā)一個方法(如某個功能的service方法)，這個方法如果中間可能出現(xiàn)異常，那么你需要考慮這個異常出現(xiàn)之后是否調(diào)用者可以處理，并且你是否希望調(diào)用者進行處理，如果調(diào)用者可以處理，并且你也希望調(diào)用者進行處理，那么就要拋出受檢異常，提醒調(diào)用者在使用你的方法時，考慮到如果拋出異常時如果進行處理。

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

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

那么，請跟著我的思路，在慢慢領(lǐng)會一下。

什么時候才需要拋異常

首先我們需要了解一個問題，什么時候才需要拋異常？異常的設(shè)計是方便給開發(fā)者使用的，但不是亂用的，筆者對于什么時候拋異常這個問題也問了很多朋友，能給出準(zhǔn)確答案的確實不多。其實這個問題很簡單，如果你覺得某些”問題”解決不了了，那么你就可以拋出異常了。

比如，你在寫一個service,其中在寫到某段代碼處,你發(fā)現(xiàn)可能會產(chǎn)生問題，那么就請拋出異常吧，相信我，你此時拋出異常將是一個最佳時機。

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

了解完了什么時候才需要拋出異常后，我們再思考一個問題，真的當(dāng)我們拋出異常時，我們應(yīng)該選用怎樣的異常呢？究竟是受檢異常還是非受檢異常呢(RuntimeException)呢？

我來舉例說明一下這個問題，先從受檢異常說起,比如說有這樣一個業(yè)務(wù)邏輯，需要從某文件中讀取某個數(shù)據(jù)，這個讀取操作可能是由于文件被刪除等其他問題導(dǎo)致無法獲取從而出現(xiàn)讀取錯誤，那么就要從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進行取之
????????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，看了以上代碼以后，你也許心中有一些想法，原來受檢異常可以控制義務(wù)邏輯，對，沒錯，通過受檢異常真的可以控制業(yè)務(wù)邏輯，但是切記不要這樣使用，我們應(yīng)該合理的拋出異常，因為程序本身才是流程，異常的作用僅僅是當(dāng)你進行不下去的時候找到的一個借口而已，它并不能當(dāng)成控制程序流程的入口或出口，如果這樣使用的話，是在將異常的作用擴大化，這樣將會導(dǎo)致代碼復(fù)雜程度的增加，耦合性會提高，代碼可讀性降低等問題。

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

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

當(dāng)我們在寫某個方法的時候，可能會偶然遇到某個錯誤，我們認(rèn)為這個問題時運行時可能為發(fā)生的，并且理論上講，沒有這個問題的話，程序?qū)?zhí)行的時候，它不強制要求調(diào)用者一定要捕獲這個異常，此時拋出RuntimeException異常。

舉個例子，當(dāng)傳來一個路徑的時候，需要返回一個路徑對應(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)的時候如果path是空，那么就拋出空指針異常(它是RuntimeException的子類),調(diào)用者不用顯示的進行try…catch…操作進行強制處理.這就要求調(diào)用者在調(diào)用這樣的方法時先進行驗證，避免發(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é)出一個結(jié)論，**RuntimeException異常和受檢異常之間的區(qū)別就是:是否強制要求調(diào)用者必須處理此異常，如果強制要求調(diào)用者必須進行處理，那么就使用受檢異常，否則就選擇非受檢異常(RuntimeException)。**一般來講，如果沒有特殊的要求，我們建議使用RuntimeException異常。

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

架構(gòu)描述

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

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

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

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

選擇一個比較簡單的業(yè)務(wù)場景，以電商中的收貨地址管理為例，用戶在移動端進行購買商品時，需要進行收貨地址管理，在項目中，提供一些給移動端進行訪問的api接口，如:添加收貨地址，刪除收貨地址，更改收貨地址，默認(rèn)收貨地址設(shè)置，收貨地址列表查詢，單個收貨地址查詢等接口。

構(gòu)建約束條件

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

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

• 用戶id
• 收貨地址實體信息

約束:

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

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

• 用戶id
• 收貨地址id

約束:

• 用戶id不能為空，且此用戶確實是存在的
• 收貨地址不能為空，且此收貨地址確實是存在的
• 判斷此收貨地址是否是用戶的收貨地址
• 判斷此收貨地址是否為默認(rèn)收貨地址，如果是默認(rèn)收貨地址，那么不能進行刪除

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

• 用戶id
• 收貨地址id

約束:

• 用戶id不能為空，且此用戶確實是存在的
• 收貨地址不能為空，且此收貨地址確實是存在的
• 判斷此收貨地址是否是用戶的收貨地址

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

• 用戶id
• 收貨地址id

約束:

• 用戶id不能為空，且此用戶確實是存在的
• 收貨地址不能為空，且此收貨地址確實是存在的
• 判斷此收貨地址是否是用戶的收貨地址

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

• 用戶id

約束:

• 用戶id不能為空，且此用戶確實是存在的

單個收貨地址查詢: 入?yún)?

• 用戶id
• 收貨地址id

約束:

• 用戶id不能為空，且此用戶確實是存在的
• 收貨地址不能為空，且此收貨地址確實是存在的
• 判斷此收貨地址是否是用戶的收貨地址

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

對于上述列出的約束條件和功能列表，我選擇幾個比較典型的異常處理場景進行分析:添加收貨地址，刪除收貨地址，獲取收貨地址列表。

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

添加收貨地址中需要對用戶id和收貨地址實體信息就行校驗，那么對于非空的判斷，我們?nèi)绾芜M行工具的選擇呢？傳統(tǒng)的判斷如下:

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

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

那我們應(yīng)該怎么進行這些入?yún)⒌呐袛嗄?#xff0c;給大家介紹兩個知識點:

• Guava中的Preconditions類實現(xiàn)了很多入?yún)⒎椒ǖ呐袛?/li>
• jsr 303的validation規(guī)范(目前實現(xiàn)比較全的是hibernate實現(xiàn)的hibernate-validator)

如果使用了這兩種推薦技術(shù)，那么入?yún)⒌呐袛鄷兊煤唵魏芏唷?*推薦大家多使用這些成熟的技術(shù)和jar工具包，他可以減少很多不必要的工作量。****我們只需要把重心放到業(yè)務(wù)邏輯上。**而不會因為這些入?yún)⒌呐袛嗟⒄`更多的時間。

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

domain介紹

根據(jù)項目場景來看，需要兩個domain模型，一個是用戶實體，一個是地址實體.

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

?addresses;
}

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

dao介紹

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

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

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

}

收貨地址操作如下:

@Repository
public?interface?IAddressDao?extends?JpaRepository

?{
}

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

Service異常設(shè)計

ok，終于到了我們的重點了，我們要完成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

?listAddresses(Integer?uid);
}


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

添加收貨地址

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

入?yún)?

• 用戶id
• 收貨地址實體信息

約束:

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

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

@Override
public?Address?createAddress(Integer?uid,?Address?address)?{
????//============?以下為約束條件???==============
????//1.用戶id不能為空，且此用戶確實是存在的
????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è)置成默認(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)完成了上述所描述的三點約束條件，當(dāng)三點約束條件都滿足時，才可以進行正常的業(yè)務(wù)邏輯，否則將拋出異常(一般在此處建議拋出運行時異常-RuntimeException)。

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

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

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

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

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

@Configuration
public?class?BeanConfigs?{

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

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

?@Autowired?????
private?Validator?validator?;

那么BeanValidators這個類是如何實現(xiàn)的？其實實現(xiàn)方式很簡單，只要去判斷jsr 303的標(biāo)注注解就ok了。

那么jsr 303的注解寫在哪里了呢？當(dāng)然是寫在address實體類中了:

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

寫好你需要的約束條件來進行判斷，如果合理的話，才可以進行業(yè)務(wù)操作，從而對數(shù)據(jù)庫進行操作。

這塊的驗證是必須的，一個最主要的原因是:這樣的驗證可以避免臟數(shù)據(jù)的插入。

如果讀者有正式上線的經(jīng)驗的話，就可以理解這樣的一個事情，**任何的代碼錯誤都可以容忍和修改，但是如果出現(xiàn)了臟數(shù)據(jù)問題，那么它有可能是一個毀滅性的災(zāi)難。**程序的問題可以修改，但是臟數(shù)據(jù)的出現(xiàn)有可能無法恢復(fù)。所以這就是為什么在service中一定要判斷好約束條件，再進行業(yè)務(wù)邏輯操作的原因了。

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

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

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

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

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

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

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

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

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

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

對于

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

定義一個特定的異常類來進行這個義務(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不能為空，且此用戶確實是存在的
????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è)置成默認(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)定性和理解性就比較強了。

刪除收貨地址:

入?yún)?

• 用戶id
• 收貨地址id

約束:

• 用戶id不能為空，且此用戶確實是存在的
• 收貨地址不能為空，且此收貨地址確實是存在的
• 判斷此收貨地址是否是用戶的收貨地址
• 判斷此收貨地址是否為默認(rèn)收貨地址，如果是默認(rèn)收貨地址，那么不能進行刪除

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

@Override
public?void?deleteAddress(Integer?uid,?Integer?aid)?{
????//============?以下為約束條件???==============
????//1.用戶id不能為空，且此用戶確實是存在的
????checkNotNull(uid);
????User?user?=?userDao.findOne(uid);
????if(null?==?user){
????????throw?new?NotFindUserException();
????}
????//2.收貨地址不能為空，且此收貨地址確實是存在的
????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)收貨地址，那么不能進行刪除
????if(address.getIsDefault()){
???????throw??new?DefaultAddressNotDeleteException();
????}

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

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

獲取收貨地址列表:入?yún)?

• 用戶id

約束:

• 用戶id不能為空，且此用戶確實是存在的

代碼如下:

??@Override
public?List

?listAddresses(Integer?uid)?{
????//============?以下為約束條件???==============
????//1.用戶id不能為空，且此用戶確實是存在的
????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è)計

大致有兩種拋出的方法:

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

這個是在設(shè)計service層異常時提到的，通過對service層的介紹，我們在service層拋出異常時選擇了第二種拋出的方式，不同的是，在api層拋出異常我們需要使用這兩種方式進行拋出:要指定api異常的類型，并且要指定相關(guān)的狀態(tài)碼，然后才將異常拋出，這種異常設(shè)計的核心是讓調(diào)用api的使用者更能清楚的了解發(fā)生異常的詳細(xì)信息。

除了拋出異常外，我們還需要將狀態(tài)碼對應(yīng)的異常詳細(xì)信息以及異常有可能發(fā)生的問題制作成一個對應(yīng)的表展示給用戶，方便用戶的查詢。(如github提供的api文檔，微信提供的api文檔等),還有一個好處:如果用戶需要自定義提示消息，可以根據(jù)返回的狀態(tài)碼進行提示的修改。

api驗證約束

首先對于api的設(shè)計來說，需要存在一個dto對象，這個對象負(fù)責(zé)和調(diào)用者進行數(shù)據(jù)的溝通和傳遞，然后dto->domain在傳給service進行操作，這一點一定要注意。

第二點，除了說道的service需要進行基礎(chǔ)判斷(null判斷)和jsr 303驗證以外，同樣的，api層也需要進行相關(guān)的驗證，如果驗證不通過的話，直接返回給調(diào)用者，告知調(diào)用失敗，不應(yīng)該帶著不合法的數(shù)據(jù)再進行對service的訪問。

那么讀者可能會有些迷惑，不是service已經(jīng)進行驗證了，為什么api層還需要進行驗證么？這里便設(shè)計到了一個概念:編程中的墨菲定律，如果api層的數(shù)據(jù)驗證疏忽了，那么有可能不合法數(shù)據(jù)就帶到了service層，進而講臟數(shù)據(jù)保存到了數(shù)據(jù)庫。

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

api異常設(shè)計

設(shè)計api層異常時，正如我們上邊所說的，需要提供錯誤碼和錯誤信息，那么可以這樣設(shè)計，提供一個通用的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以默認(rèn)地址不能刪除為例:

public?class?ApiDefaultAddressNotDeleteException?extends?ApiException?{

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

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

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è)計完了，在此多說一句，AddressErrorCode錯誤碼類存放了可能出現(xiàn)的錯誤碼，更合理的做法是把他放到配置文件中進行管理。

api處理異常

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

此處僅以添加地址為例:

?@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){//未知錯誤
????????throw?new?ApiException(e);
????}
????AddressDTO?resultDTO?=?new?AddressDTO();
????BeanUtils.copyProperties(result,resultDTO);
????resultDTO.setUid(result.getUser().getId());

????return?resultDTO;
}

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

api異常轉(zhuǎn)化

已經(jīng)講解了如何拋出異常和何如將service異常轉(zhuǎn)化為api異常，那么轉(zhuǎn)化成api異常直接拋出是否就完成了異常處理呢？答案是否定的，當(dāng)拋出api異常后，我們需要把api異常返回的數(shù)據(jù)(json or xml)讓用戶看懂，那么需要把api異常轉(zhuǎn)化成dto對象(ErrorDTO),看如下代碼:

@ControllerAdvice(annotations?=?RestController.class)
class?ApiExceptionHandlerAdvice?{

/**
?*?Handle?exceptions?thrown?by?handlers.
?*/
@ExceptionHandler(value?=?Exception.class)
@ResponseBody
public?ResponseEntity?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?responseEntity?=?new?ResponseEntity<>(errorDTO,HttpStatus.valueOf(response.getStatus()));return?responseEntity;
}@Setter@Getterclass?ErrorDTO{private?Long?errorCode;private?String?tip;
}
}

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

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

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

總結(jié)

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

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

• 面試官問：MySQL的自增ID用完了，怎么辦？

• ArrayList插入1000w條數(shù)據(jù)之后，我懷疑了jvm...

• 螞蟻二面，面試官問我零拷貝的實現(xiàn)原理，當(dāng)場懵了…

最近面試BAT，整理一份面試資料《Java面試BAT通關(guān)手冊》，覆蓋了Java核心技術(shù)、JVM、Java并發(fā)、SSM、微服務(wù)、數(shù)據(jù)庫、數(shù)據(jù)結(jié)構(gòu)等等。

獲取方式：點“在看”，關(guān)注公眾號并回復(fù)?666?領(lǐng)取，更多內(nèi)容陸續(xù)奉上。

明天見(｡･ω･｡)ﾉ?

總結(jié)

以上是生活随笔為你收集整理的java build path entries 为空_同事的代码简直没法看，我来教你如何更优雅的设计Java异常...的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。