異常在Java中有兩種分類：Error（OutOfMemoryError之類的我們自己程式無法處理的非常嚴重的錯誤，Java推薦不catch，讓程式隨之崩潰）、Excepiton（NullPointerException之類的並不致命的錯誤，Java覺得indicates conditions th ...

異常在Java中有兩種分類：Error（OutOfMemoryError之類的我們自己程式無法處理的非常嚴重的錯誤，Java推薦不catch，讓程式隨之崩潰）、Excepiton（NullPointerException之類的並不致命的錯誤，Java覺得indicates conditions that a reasonable application might want to catch，推薦catch），本文以下內容涉及到的都是Exception。

本文會結合REST API與Spring的一些具體實踐來探討一下異常處理的套路。

異常與異常處理機制的意義

關於異常是拿來乾什麼的，很多人老程式員認為就是拿來我們Debug的時候排錯的，當然這一點確實是異常機制非常大的一個好處，但異常機制包含著更多的意義。

關註業務實現。異常機制使得業務代碼與異常處理代碼可以分開，你可以將一些你調用資料庫操作的代碼寫在一個方法里而只需要在方法上加上throw DB相關的異常。至於如何處理它，你可以在調用該方法的時候處理或者甚至選擇不處理，而不是直接在該方法內部添加上if判斷如果資料庫操作錯誤該如何辦，這樣業務代碼會非常混亂。
統一異常處理。與上一點有所聯繫。我當前所在項目的實踐是，自定義業務類異常，在Controller或Service中拋出，讓後使用Spring提供的異常介面統一處理我們自己在內部拋出的異常。這樣一個異常處理架構就非常明瞭。
程式的健壯性。如果沒有異常機制，那麼來了個對空對象的某方法調用怎麼辦呢？直接讓程式掛掉？這令人無法接受，當然，我們自己平時寫的一些小的東西確實是這樣，沒有處理它，讓後程式掛了。但在web框架中，可以利用異常處理機制捕獲該異常並將錯誤信息傳遞給我們然後繼續處理下個請求。所以異常對於健壯性是非常有幫助的。

異常處理（又稱為錯誤處理）功能提供了處理程式運行時出現的任何意外或異常情況的方法。異常處理使用 try、catch 和 finally 關鍵字來嘗試可能未成功的操作，處理失敗，以及在事後清理資源。

先分類(dian cai)吧

我把異常根據意義成三種：業務、系統、代碼異常，不同的異常採用不同的處理方式。

業務異常

@GetMapping("/{id}")
public ReservationDetail getDetail(@PathVariable String id) {
    ReservationDetail result = applicationService.getReservationDetail(id);
    if (result == null) {
        throw new InfoNotFoundExcepiton("reservation with id=" + id + " is not exist");
    }

    return result;
}

以上代碼當沒有查到數據的時候拋出一個InfoNotFoundExcepiton異常，查詢一個信息但不存在，沒有任何系統級別的錯誤發生，而是數據確實不存在，此時屬於業務異常。這個例子比較局限，其他的場景可能有一個用戶想訪問某個API，但是沒有許可權，此時可以返回無許可權的業務異常。

將所有業務異常拋出，並通過Spring提供的介面進行統一處理，要註意的是，返回碼也是需要分別標示的，對於意義不同的業務異常，對應的錯誤返回碼也是需要被指定的：

@RestControllerAdvice
public class ControllerAdvice {

    private static final Logger logger = LoggerFactory.getLogger(ControllerAdvice.class);

    @ExceptionHandler(Throwable.class)
    @ResponseStatus(HttpStatus.INTERNAL_SERVER_ERROR)
    public ErrorResult handleOtherException(Throwable e) {
        RestControllerAdvice
        return new ErrorResult(ErrorCode.UNKNOWN, e.getMessage());
    }

    @ExceptionHandler(ResourceAccessException.class)
    @ResponseStatus(HttpStatus.NOT_FOUND)
    public ErrorResult handleResourceNotFoundException(ResourceAccessException e) {
        logger.error(e.getMessage(), e);
        return new ErrorResult(ErrorCode.RESOURCE_NOT_FOUND, e.getMessage());
    }

}

這種異常處理方式個人認為在我們代碼中越多越好，如果能在代碼中涵蓋業務中的很多邊界值，對於整體應用的健壯性提升有著非常大的幫助，並且對於前端來說，前端可以根據此異常信息給予用戶更加明確友好的錯誤提示：

攜帶錯誤碼為500的錯誤請求：
{
    "message": "cannot find pre inspection base info by order id: 1",
    "error_code": "SERVICE_REQUEST_ERROR"
}

系統異常

這種異常在調試時非常常見，要麼是某個服務掛掉了，或者超時這樣的情況，跟業務沒有關係，也不是代碼中的BUG導致的，這個時候我們必須設計好一個預案去cover這種風險。

在微服務架構中，這種情況時有發生，如在我翻譯過的這篇文章中提到的，使用Netflix Hystrix解決，在Spring Cloud中已經攜帶該模塊。具體如下：

網路超時 - 不會無限期等待並使用超時策略。這可以確定資源不會被無限期被捆綁在一起
限制未完成的請求的數量 - 對於客戶端可以使用特定服務的未完成請求數量強加一個上限。如果到達限制，提出額外的請求可能沒有意義，這些嘗試需要立即失敗。
使用斷路器模式 - 跟蹤成功和失敗的數量。如果錯誤率超過預定的閾值，斷路器跳閘，以便以後的嘗試失敗。如果很多請求失敗，建議服務設為不可用，發請求也是沒有意義的。但超時之後，客戶端應該再次嘗試，如果成功，關閉斷路器。
提供備用邏輯 - 當請求失敗後執行備用邏輯。比如返回緩存數據或者預設值比如空的推薦。

那麼問題來了，這些異常可以與其他異常分類統一格式返回給前端嗎？

1	`@ExceptionHandler(Throwable.class)`

這行代碼捕捉了所有的異常，包括Error級別的，這是根據特定項目需求來確定的，所以即使是Error也需要記錄下來，出錯之後方便錯誤的排查。

代碼異常

我把代碼中存在的BUG叫做代碼異常，與系統異常不同的是，這種異常只能儘量避免與預防。比如程式員沒有考慮到的情況導致空指針異常、SQL語句編寫錯誤導致SQLException。線上上環境是非常嚴重的錯誤，需要立馬開hotfix分支去修的，因為沒有編寫對應的業務處理方式，最嚴重的後果可能導致某個用戶扣了錢但是沒有顯示支付成功。

和系統異常一樣，這些異常由於是Throwable異常類下的異常，所以會被返回給前端。

異常處理流程與規範

異常處理流程在微服務架構中可能會比直接向前端發送異常信息這個過程麻煩一些，如Service向BFF層級傳遞異常一級。

異常在服務之間的傳遞

API Gateway (with Zuul) => BFF => 某服務

由於BFF與服務之間是通過Feign連接，所以我們需要自己統一一下錯誤格式成為業務相關的格式返回給前端而不是直接將細化某個Java異常類的全部異常信息交給前端。

在這張圖中，在BFF中檢測參數是否匹配，在Service中檢測是否資源存在，如果在BFF中拋出異常，則將INVALID_PARAMETER異常返回給前端，如果在Service中拋出異常，則將SERVICE_REQUEST_ERROR返回給前端。也就是將異常做出簡單的分類：業務異常、非業務異常，非業務異常中可以像上面分類一樣繼續分類。

約定返回格式

前後端統一錯誤格式，需要規定如下：

返回格式：JSON
返回請求狀態碼：根據不同請求對應的狀態碼意義返回
返回具體格式如下

{
   "message": "reservation details doesn't exist with id: xxx",
   "errorCode": "SERVICE_REQUEST_ERROR",
}

Spring Cloud中異常處理的套路