一種避免大量If-else代碼的新思路
哈嘍,各位代碼戰士們,我是Jensen,一個夢想著和大家一起在代碼的海洋里遨游,順便撿起那些散落的知識點的程序員小伙伴。
今天,我要給大家帶來一個超級無敵霹靂的編碼新招式,只要看完,保證你的代碼像用了某某洗發水一樣,不僅去屑還更柔順。
咱們要聊的是那些讓人又愛又恨的技術點:自定義異常、全局異常捕獲、斷言。
一、控制異常流程
首先,讓我們來聊聊自定義異常。
你知道的,在Java的世界里,我們通常用if-else語句來檢查那些讓人頭疼的條件。
比如用戶登錄:
// 偽代碼
if (驗證碼 != 8888) {
return "驗證碼錯誤";
}
// 處理其他業務邏輯
return "登錄成功";
但是,你有沒有想過,如果不用if-else,而是用異常來控制流程,會怎樣呢?
比如,你的登錄方法里,驗證碼不正確,不是返回一個錯誤信息,而是“砰”地一聲拋出個異常。
// 偽代碼
if (驗證碼 != 8888) {
throw new ServiceException("驗證碼錯誤");
}
// 處理其他業務邏輯
return "登錄成功";
聽起來是不是有點瘋狂?但這就是自定義異常的魅力所在,它能讓你的代碼看起來像是在演電影,每個異常都是一個劇情轉折。
這里封裝了一個業務類異常類ServiceException,該異常類繼承了運行時異常RuntimeException:
/**
* 服務異常,可用于控制業務異常流程,拋出后由統一異常增強類捕獲,返回友好提示
*
* @author Jensen
* @公眾號 架構師修行錄
*/
@Data
public class ServiceException extends RuntimeException {
protected Integer code;
public ServiceException(Integer code, String message) {
super(message);
this.code = code;
}
public ServiceException() {
this(500, "請求成功但是服務異常");
}
public ServiceException(String message) {
this(500, message);
}
public ServiceException(Throwable e) {
this(e.getMessage());
}
}
使用自定義異常來代替傳統的if-else語句進行錯誤處理和流程控制,有其優缺點:
優點:
- 提高代碼可讀性:自定義異常可以讓你更清晰地表達錯誤情況,使得代碼的意圖更容易理解。
- 集中錯誤處理:通過拋出和捕獲異常,你可以將錯誤處理邏輯集中到特定的位置,而不是分散在代碼的多個地方。
- 易于維護:當需要修改或擴展錯誤處理邏輯時,使用異常機制可以更容易地進行維護和升級。
- 支持多路選擇:在某些情況下,異常可以用于實現多路選擇結構,通過不同的異常類型來區分不同的執行路徑。
- 資源管理:異常處理機制通常與資源管理(如文件關閉、數據庫連接釋放等)結合使用,確保資源在使用完畢后得到正確釋放。
缺點:
- 性能開銷:異常處理通常比條件判斷要慢,因為它涉及到棧展開和異常對象的創建。
- 濫用風險:異常機制有時會被濫用,例如用于正常的流程控制,這可能會導致性能問題和難以理解的代碼。
- 調試困難:異常可能會使調試變得更加困難,特別是在復雜的異常傳播和處理過程中。
- 異常類型管理:隨著項目的發展,可能會有大量的自定義異常類型,管理這些異常類型并確保它們的適當使用可能會變得復雜。
- 語言特性依賴:使用異常處理可能依賴于特定的編程語言特性,這可能會限制代碼的移植性。
總的來說,自定義異常在處理錯誤和異常情況時提供了一種強大而靈活的機制,我覺得可以使用,但不能濫用,常規的還是要使用if-else控制,涉及API的中斷流程可以快速跳出內部,并且R對象可無須傳遞進Service層。
二、全局異常捕獲
想象一下,你的業務代碼里拋出了一大堆異常,你總不能把這些異常原封不動地扔給API的使用者吧。
這時候,@RestControllerAdvice就像是那個超級英雄,跳出來拯救世界,把所有的異常都捕獲起來,然后優雅地包裝成一個個友好的響應。
@RestControllerAdvice 是 Spring MVC 中的一個注解,用于定義一個全局的異常處理類,該類可以捕獲和處理 Spring 應用中發生的特定類型的異常。這個注解通常與 @ExceptionHandler 注解一起使用,來定義處理特定異常的方法。
@RestControllerAdvice 的主要作用和特點包括:
- 全局異常處理:通過在類上使用 @RestControllerAdvice 注解,你可以定義一個類來全局處理控制器(Controller)中拋出的異常。
- 減少重復代碼:你不需要在每個控制器中編寫相同的異常處理邏輯。通過定義一個全局的異常處理類,可以統一處理特定類型的異常,從而減少代碼重復。
- 自定義錯誤響應:可以自定義異常的響應格式,例如返回 JSON 對象,包含錯誤信息、狀態碼等,以提供更友好的錯誤提示給前端。
- 支持多控制器:一個 @RestControllerAdvice 類可以為多個控制器提供異常處理支持,無論這些控制器是否位于同一個包路徑下。
- 組合使用:可以定義多個 @RestControllerAdvice 類,并通過 basePackages 或 basePackageClasses 屬性來指定它們所影響的控制器包路徑。
- 支持繼承:如果多個控制器有相似的異常處理需求,可以通過繼承一個基礎的異常處理類來實現代碼復用。
捕獲業務異常ServiceException后,封裝R對象返回給接口調用方:
@RestControllerAdvice
public class GlobalRestExceptionAdvice {
@ExceptionHandler({ServiceException.class})
public R<Map<String, String>> serviceException(HttpServletRequest request, ServiceException e) {
return R.fail(e.getCode(), e.getMessage(), null);
}
}
到這里,我們就可以通過拋出ServiceException來實現異常流程的控制了,并且方法上注解了@Transactional實現的事務控制,在拋出異常后也是能正常回滾的。
三、封裝使用業務斷言
在Java中,斷言就像是那個總是在后臺默默支持你的好朋友,它在開發和測試階段幫你檢查那些邏輯錯誤。
但是,別忘了,它也是有脾氣的,一旦到了生產環境,它就罷工了。所以,記得在需要的時候啟用它,不需要的時候,就讓它好好休息。
assert condition : "This is an error message.";
斷言的特點:
- 條件檢查:斷言用于檢查程序的預期條件,如果條件不滿足,則拋出異常。
- 調試時有用:斷言在開發和測試階段非常有用,可以幫助開發者快速定位問題。
- 性能考慮:由于斷言可能會影響程序性能,因此在生產環境中通常不啟用斷言。
- 非正式錯誤處理:斷言不是錯誤處理的一部分,它不適用于處理那些預期會發生的情況。
使用斷言的注意事項:
- 性能影響:斷言會增加額外的性能開銷,因為每次斷言都會計算布爾表達式的值。
- 生產環境:在生產環境中,斷言應該被禁用,以避免不必要的性能損耗。
- 異常處理:斷言拋出的是 AssertionError,這是一種特殊的 Error,通常不應該被應用程序捕獲或處理。
斷言是Java語言的一個特性,它的使用應該謹慎,主要限于開發和測試階段,以確保生產環境中的程序性能和穩定性。
我們借鑒斷言這種設計思想,針對業務異常進一步封裝,形成 “業務斷言”,主要目標只有一個:
管理我們對代碼的期望。
先定義一個業務斷言工具類BizAssert:
/**
* 業務斷言類,斷言不通過將拋出ServiceException
*/
@UtilityClass
public class BizAssert {
public <T> T notNull(T dontNull) {
if (dontNull == null) {
throw new ServiceException("this object must not be null");
}
return dontNull;
}
public void notBlank(String dontBlank) {
if (dontBlank == null || dontBlank.length() == 0) {
throw new ServiceException("this string must not be null or blank");
}
}
public <E, T extends Iterable<E>> T notEmpty(T dontEmpty) {
if (dontEmpty == null || !dontEmpty.iterator().hasNext()) {
throw new ServiceException("this collection must not be null or empty");
}
return dontEmpty;
}
public <T> T isOk(IR r) {
if (r == null || !r.isOk()) {
throw new ServiceException(r == null ? "this result must not be null" : r.getMsg());
}
return r.getData();
}
public <T> T notNull(IR r) {
if (r == null || !r.isOk() || r.getData() == null) {
throw new ServiceException(r == null ? "this result must not be null" : r.getMsg());
}
return r.getData();
}
}
使用業務斷言:
// 從數據庫中查詢出用戶
User user = UserQuery.builder().id(userId).build().getOne();
// 業務斷言,我希望查出來的用戶不能為null,否則后續業務會報錯
BizAssert.notNull(user);
// 其他針對user的業務處理邏輯
Map<String, String> data = new HashMap<>();
data.put("girl-friend", user.getName());
四、寫在最后
Gitee源碼地址:
https://gitee.com/jensvn/d3boot(例行賒Star)
D3boot基礎框架具體的使用方式見源碼的README.md文件,這里不再贅述。
能寫一行代碼的事,絕不寫3行5行,適度封裝,讓代碼更優雅!