如何設計優雅的 Java 異常？

}

我們來關註一下實作:

新增收貨地址

首先再來看一下之前整理的限制條件:

# 入參:

用戶id

收貨地址實體資訊

約束:

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

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

# 如果用戶尚未有收貨地址，當此收貨地址建立時設定成預設收貨地址

先看以下程式碼實作:

@Override

public Address createAddress(Integer uid, Address address) {

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

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

Preconditions.checkNotNull(uid);

User user = userDao.findOne(uid);

# if(null == user){

# throw new RuntimeException("找不到目前使用者!");

# }

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

BeanValidators.validateWithException(validator, address);

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

if(ObjectUtils.isEmpty(user.getAddresses())){

# address.setIsDefault(true);

}

//============ 以下為正常執行的業務邏輯 ==============

address.setUser(user);

# Address result = addressDao.save(address);

return result;

}

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

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

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

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

當然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中進行注入便可以使用了:

@Autowired

private Validator validator ;

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

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

# @Entity

# @Setter

# @Getter

# public class Address {

@Id

@GeneratedValue

private Integer id;

# @NotNull

private String province;//省

@NotNull

private String city;//城市

@NotNull

private String county;//區

private Boolean isDefault = false;//是否是預設位址

@ManyToOne(cascade={CascadeType.ALL})

# @JoinColumn(name="uid")

private User user;

# }

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

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

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

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

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

實體屬性約束(滿足jsr 303等基礎判斷)

業務條件限制(需求提出的不同的業務限制)

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

ok,基本上介紹瞭如何做一個基礎的判斷，那麼再回到異常的設計問題上，上述程式碼已經很清楚的描述如何在適當的位置合理的判斷一個異常了，那麼如何合理的拋出異常呢？

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

拋出帶狀態碼RumtimeException異常

拋出指定類型的RuntimeException例外

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

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

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

對於

1throw new RuntimeException("找不到目前使用者!");

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

public class NotFindUserException extends RuntimeException {

public NotFindUserException() {

super("找不到此使用者");

# }

public NotFindUserException(String message) {

# super(message);

# }

}

然後將此處改為:

1throw new NotFindUserException("找不到目前使用者!");

or

1throw 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("找不到目前使用者!");

}

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

BeanValidators.validateWithException(validator, address);

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

if(ObjectUtils.isEmpty(user.getAddresses())){

# address.setIsDefault(true);

}

//============ 以下為正常執行的業務邏輯 ==============

address.setUser(user);

# Address result = addressDao.save(address);

return result;

}

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

刪除收貨地址:

入參:

用戶id

收貨地址id

約束:

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

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

# 判斷此收貨地址是否為用戶的收貨地址

判斷此收貨地址是否為預設收貨地址，如果是預設收貨地址，那麼不能進行刪除

它與上述新增收貨地址類似，故不再贅述，delete的service設計如下:@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.判斷此收貨地址是否為預設收貨地址，如果是預設收貨地址，那麼不能進行刪除

# if(address.getIsDefault()){

throw new DefaultAddressNotDeleteException();

# }

//============ 以下為正常執行的業務邏輯 ==============

addressDao.delete(address);

}

設計了相關的四個異常類別:NotFindUserException,NotFindAddressException,NotMatchUserAddressException,DefaultAddressNotDeleteException.根據不同的業務需求拋出不同的例外。

取得收貨地址清單:

入參:

用戶id

約束:

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

程式碼如下:@Override

public List