3 回答

TA貢獻1845條經驗 獲得超8個贊
不要那樣做。
拋出你的異常,或者讓它從你的調用堆棧中逃逸。使用@ControllerAdvice
(or @RestControllerAdvice
) with@ExceptionHandler
代替。
您可以擴展抽象類ResponseEntityExceptionHandler
,并提供額外的處理方法。從長遠來看,這對于干凈的應用程序設計很重要。
如果您打算返回帶有狀態碼的錯誤200
,我想了解原因。我目睹了開發人員為錯誤請求提供響應,200
只是因為在客戶端的另一個代碼分支中處理 HTTP 錯誤似乎“困難”。

TA貢獻1816條經驗 獲得超4個贊
一般在請求不成功時會返回錯誤信息,與 4/5xx 錯誤碼一致。通常使用 Spring,您可以使用異常處理程序來管理這種情況,如此處所示,您可以在其中定義不同的響應主體。還有一個很好的做法:使用信封管理所有回復,我給你舉個例子
{
status: 200,
message: 'user retrieved',
result:
[
{foo1:"bar1"},
.....
]
}
或者
{
status: 400,
message: 'bad request',
error:
{
reason : "wrong field xxx in request"
}
}
通過這種方式,客戶端可以處理請求并向用戶提供有用的信息。為此,您必須定義一個用于所有響應的類,并且應該封裝結果或錯誤

TA貢獻1853條經驗 獲得超9個贊
首先,您應該知道已經有一個類似的類 org.springframework.http.ResponseEntity,您可以返回該對象作為 API 的響應。它可以包裝您的響應正文 - 列表、帳戶、產品等,并有可能覆蓋默認的 Http 狀態。
因此,基于此示例,您可以編寫自己的簡單包裝類,如下所示:
public class Response<T>
{
private GenericErrorClass error;
private T body;
// constructors + getters + setters
}
當您的 API 方法應該返回時,List<Customer>您將返回Response<List<Customer>>,以同樣的方式返回其他對象。
但是,我建議您捕獲異常并將詳細的錯誤消息 + 相應的錯誤代碼發送到 API 客戶端。從設計的角度來看,這要好得多。在這里實現這一點是一個很好的閱讀。
如果您有時間考慮 API 的設計,我會推薦本指南。
添加回答
舉報