如何設計優雅的 Java 異常？
- 王林轉載
- 2023-04-26 11:25:071142瀏覽
什麼時候才需要拋異常
首先我們要了解一個問題，什麼時候才需要拋異常？異常的設計是方便給開發者使用的，但不是亂用的，筆者對於什麼時候拋異常這個問題也問了很多朋友，能給出準確答案的確實不多。其實這個問題很簡單，如果你覺得某些」問題」解決不了了，那麼你就可以拋出異常了。例如，你在寫一個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.如下:
# 應該選用哪一種異常
透過以上的描述和舉例，可以總結出一個結論，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
addresses;# }
ok,上邊是一個模型關係，使用者-收貨地址的關係是1-n的關係。上邊的@Data是使用了一個叫做lombok的工具，它自動生成了Setter和Getter等方法，用起來非常方便，有興趣的讀者可以自行了解一下。
dao介紹
# 資料連接層，我們使用了spring-data-jpa這個框架，它要求我們只需要繼承框架提供的接口，並且按照約定對方法進行取名，就可以完成我們想要的資料庫操作。
用戶資料庫操作如下:
@Repository
public interface IUserDao extends JpaRepository
}
收貨地址操作如下:
@Repository
public interface IAddressDao extends JpaRepository
}
正如讀者所看到的，我們的DAO只需要繼承JpaRepository,它就已經幫我們完成了基本的CURD等操作，如果想了解更多關於spring-data的這個項目，請參考一下spring的官方文檔，它比不方案我們對異常的研究。
Service異常設計
ok，終於到了我們的重點了，我們要完成service一些的部分操作:新增收貨地址，刪除收貨地址，取得收貨地址清單.
# 首先看我的service介面定義:
public interface IAddressService {
# /**
* 建立收貨地址
* @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);}
我們來關註一下實作:
新增收貨地址
首先再來看一下之前整理的限制條件:
# 入參:
用戶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
listAddresses(Integer uid) {# //============ 以下為約束條件 ==============
# //1.使用者id不能為空，且此使用者確實是存在的
checkNotNull(uid);
# User user = userDao.findOne(uid);
# if(null == user){
# throw new NotFindUserException();
}
//============ 以下為正常執行的業務邏輯 ==============
User result = userDao.findOne(uid);
# return result.getAddresses();
}
api異常設計
大致上有兩種拋出的方法:
# 拋出帶狀態碼RumtimeException異常
拋出指定類型的RuntimeException例外
這是在設計service層異常時提到的，透過對service層的介紹，我們在service層拋出異常時選擇了第二種拋出的方式，不同的是，在api層拋出異常我們需要使用這兩種方式進行拋出:要指定api異常的類型，並且要指定相關的狀態碼，然後才將異常拋出，這種異常設計的核心是讓調用api的用戶更能清楚的了解發生異常的詳細信息，除了拋出異常外，我們還需要將狀態碼對應的異常詳細信息以及異常有可能發生的問題製作成一個對應的表展示給用戶，方便用戶的查詢。 （如github提供的api文檔，微信提供的api文檔等）,還有一個好處:如果用戶需要自訂提示訊息，可以根據返回的狀態碼進行提示的修改。
api驗證約束
首先對於api的設計來說，需要存在一個dto對象，這個對象負責和調用者進行資料的溝通和傳遞，然後dto->domain在傳給service進行操作，這一點一定要注意，第二點，除了說的service需要進行基礎判斷(null判斷)和jsr 303驗證以外，同樣的，api層也需要進行相關的驗證，如果驗證不通過的話，直接返回給調用者，告知調用失敗，不應該帶著不合法的資料再進行對service的訪問，那麼讀者可能會有些迷惑，不是service已經進行驗證了，為什麼api層還需要進行驗證麼？這裡便設計到了一個概念:程式設計中的墨菲定律，如果api層的資料驗證疏忽了，那麼有可能不合法資料就帶到了service層，進而講髒資料儲存到了資料庫。
所以縝密程式設計的核心是:永遠不要相信收到的資料是合法的。
api異常設計
設計api層異常時，正如我們上邊所說的，需要提供錯誤碼和錯誤訊息，那麼可以這樣設計，提供一個通用的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);
}
公共ApiException（字串訊息，Throwable e）{
# this(null,訊息,null,e);
}
公共 ApiException(){
# }
公共 ApiException(Throwable e){
超級(e);
}
公長 getErrorCode() {
傳回錯誤代碼；
}
公有無效setErrorCode（長錯誤代碼）{
this.errorCode = errorCode;
}
公用物件 getData() {
# 返回資料；
}
公共無效setData（物件資料）{
# this.data = 資料;
}
}
然後分別定義api層異常：ApiDefaultAddressNotDeleteException,ApiNotFindAddressException,ApiNotFindUserException,ApiNotMatchUserAddressException。
# 以預設位址不能刪除為例：
公共類別 ApiDefaultAddressNotDeleteException 擴充 ApiException {
公共ApiDefaultAddressNotDeleteException（字串訊息）{
超級（AddressErrorCode.DefaultAddressNotDeleteErrorCode，訊息，空）;
}
}
AddressErrorCode.DefaultAddressNotDeleteErrorCode就是需要提供給呼叫者的錯誤碼。錯誤碼類別如下：
公共抽象類別AddressErrorCode {
public static Final Long DefaultAddressNotDeleteErrorCode = 10001L;//預設位址不能刪除
# public static final Long NotFindAddressErrorCode = 10002L;//找不到此收貨地址
# public static final Long NotFindUserErrorCode = 10003L;//找到此使用者
public static final Long NotMatchUserAddressErrorCode = 10004L;//使用者與收貨地址不符
}
ok，那麼api層的異常就已經設計完了，在此多說一句，AddressErrorCode錯誤碼類別存放了可能出現的錯誤碼，更合理的做法是我們把配置文件中進行管理。
api處理異常
api層會呼叫service層，然後來處理service中出現的所有異常，首先，需要保證一點，一定要讓api層非常輕，基本上首先一個轉發的功能就好（介面參數，傳遞給service參數，返回給呼叫者數據，這三個基本功能)，然後需要在傳遞給服務參數的那個方法上調用進行異常處理。
這裡僅以新增位址為例：
@Autowired
私人 IAddressService 位址服務;
# /**
* 新增收貨地址
* @param addressDTO
# * @return
*/
@RequestMapping(方法 = RequestMethod.POST)
public AddressDTO add(@Valid @RequestBody AddressDTO addressDTO){
位址 位址 = 新位址();
# BeanUtils.copyProperties(addressDTO,地址);
# 地址結果；
試 {＃＃＃＃＃＃ 結果 = addressService.createAddress(addressDTO.getUid(), 位址);
# }catch (NotFindUserException e){
throw new ApiNotFindUserException("找不到該使用者");
}catch（異常e）{//未知錯誤
拋出新的 ApiException(e);
}
AddressDTO resultDTO = new AddressDTO();
BeanUtils.copyProperties(結果,結果DTO);
# resultDTO.setUid(result.getUser().getId());
# 返回結果DTO;
}
這裡的處理方案是呼叫服務時，判斷異常的類型，然後將任何服務異常轉化成api異常，然後發送api異常，這是常用的一種異常轉換方式。類似刪除收貨地址和取得收貨地址也類似這樣的處理，在這裡，不再贅述。
# api異常轉換
已經講解瞭如何發送異常以及如何如將service異常轉換為api異常，那麼轉換成api異常直接發送是否就完成了異常處理呢？返回的資料(json或xml)讓使用者看懂，那麼需要把api異常轉換成dto物件(ErrorDTO)，看如下程式碼：
# @ControllerAdvice(註解 = RestController.class)
# 類別 ApiExceptionHandlerAdvice {
/**
* 處理處理程序拋出的例外。
#*/
@ExceptionHandler(value = Exception.class)
@ResponseBody
公共 ResponseEntity
# ErrorDTO errorDTO = new ErrorDTO();
if(ApiException 例外實例){//api異常
# ApiException apiException = (ApiException)異常;
errorDTO.setErrorCode(apiException.getErrorCode());
}else{//未知異常
errorDTO.setErrorCode(0L);
# }
errorDTO.setTip(exception.getMessage());
ResponseEntity
返回響應實體；
}
@賽特
@蓋特
類別 ErrorDTO{
private Long errorCode;
# 私有字串提示；
}
}
ok,這樣就完成了api異常轉化成用戶可以讀取懂的DTO物件了，程式碼中用到了@ControllerAdvice，這是spring MVC提供的一個特殊的切面處理。
當呼叫api介面發生異常時，使用者也可以收到正常的資料格式了,例如當沒有使用者(uid為2)時，卻為這個使用者新增收貨地址,postman(Google plugin 用於模擬http請求)之後的數據:
{
"errorCode": 10003,
"tip": "找不到該使用者"
# }
以上是如何設計優雅的 Java 異常？的詳細內容。更多資訊請關注PHP中文網其他相關文章！