我在控制器中使用異常處理程序，如下所示：@ExceptionHandler(Exception.class)@ResponseStatus(HttpStatus.CONFLICT)@ResponseBodypublic ApiError handleException(Exception e) { logger.error("Exception occurred {}", e.getMessage(), e); return new ApiError(HttpStatus.CONFLICT, e.getMessage());}現(xiàn)在我想根據(jù)異常類型選擇正確的響應(yīng)狀態(tài)。最佳實(shí)踐中是否有任何關(guān)系？現(xiàn)代方法是在任何地方使用運(yùn)行時(shí)異常，所以我不確定4XX對(duì)所有運(yùn)行時(shí)異常使用響應(yīng)代碼總是正確的。你能澄清一下嗎？聚苯乙烯我明白 4XX 是客戶端錯(cuò)誤，但 5XX 是服務(wù)器錯(cuò)誤。
3 回答
largeQ
TA貢獻(xiàn)2039條經(jīng)驗(yàn) 獲得超8個(gè)贊
你走在正確的軌道上。在我看來，4xx為所有未經(jīng)檢查的異常返回響應(yīng)代碼并不總是正確的。我寧愿將這些異常的定義子集映射到4xx響應(yīng)代碼，其他任何內(nèi)容都應(yīng)該是內(nèi)部服務(wù)器錯(cuò)誤，因此是500響應(yīng)代碼。
@ResponseStatus(value=HttpStatus.NOT_FOUND)
public class EntityNotFoundException extends RuntimeException {
// ...
}
@Service如果未找到實(shí)體，則可以從帶注釋的類拋出此異常。對(duì)于其他情況，您也可以定義自定義異常。你也可以堅(jiān)持你@ExceptionHandler，但是你必須自己做映射。
我應(yīng)該是將異常映射到相關(guān) HTTP 響應(yīng)代碼的好習(xí)慣：
錯(cuò)誤的請(qǐng)求：
400未找到：
404禁止：
403內(nèi)部服務(wù)器錯(cuò)誤：
500
此外，如果您的請(qǐng)求成功，請(qǐng)不要忘記返回以下（或任何其他）響應(yīng)代碼之一。
好的：
200創(chuàng)建：
201
以上響應(yīng)代碼是常用的。當(dāng)然，還有更多，但大多數(shù) API 只需要一小部分。通過正確的映射，客戶端可以更輕松地了解可能出錯(cuò)（或正確）的內(nèi)容，然后可以執(zhí)行進(jìn)一步的操作或顯示客戶端所需的信息。例如：
200: 顯示成功信息403: 重定向到登錄頁面400: 如果提交了表單，則顯示錯(cuò)誤
如果出現(xiàn)任何問題，在正文中包含有意義的信息也是一種很好的做法。這也回答了以下問題：“如果我無法將異常映射到現(xiàn)有響應(yīng)代碼，我該怎么辦？”。我問過自己同樣的問題，答案很簡單。嘗試將其映射到最接近的響應(yīng)代碼并在正文中包含其他任何內(nèi)容。
如果客戶端缺少參數(shù)，您可以使用以下方法：
{ "error" : "Bad Request - Your request is missing parameter 'id'. Please verify and resubmit." }或者對(duì)于上述表單錯(cuò)誤（響應(yīng)代碼400）：
{
"errors": [
"username": "AlreadyInUse",
]}在返回正文中的信息時(shí)，請(qǐng)確保堅(jiān)持使用一種格式。否則，工作起來很痛苦。
弒天下
TA貢獻(xiàn)1818條經(jīng)驗(yàn) 獲得超8個(gè)贊
恕我直言，它不依賴于運(yùn)行時(shí)與檢查異常模式，而是依賴于語義正確的區(qū)分。
默認(rèn)情況下，異常類型不反映此語義。
5xx 是在告訴客戶您那邊出了點(diǎn)問題。
4xx 告訴客戶端 API 使用“錯(cuò)誤”或未按預(yù)期方式使用。
您可以使用運(yùn)行時(shí)或檢查異常來實(shí)現(xiàn) 4xx 或 5xx 狀態(tài)代碼。這僅取決于您自己的軟件架構(gòu)。
我不會(huì)從檢查或運(yùn)行時(shí)異常的區(qū)別中確定 4xx/5xx（似乎損害了最小驚訝原則 - POLA）
添加回答
舉報(bào)
0/150
提交
取消