最近在做一個介面統一返回值問題,我在service層 var test = GetFromDB() test 為null我想直接它提示"設備不存在"),我想在這裡返回特定信息給前端,現在看有兩種方式:

第一種返回值返回統一的包裝類("這樣的話每個介面都要返回被這個類包裝"裡面有{data, message, code} 我感覺每個返回值都要被這個類封裝很醜

第二種直接throw 異常 異常包含對象信息,然後再全局異常處理進行包裝

各位覺得哪一種更好?

第一種:

第二種:

目前討論下來大部分人覺得直接拋異常給異常處理器處理好一點!


寫個exception filter就可以了

除了事務相關操作,否則不要隨便寫

try …… catch,web層統一捕獲exception

在http://asp.net core 中,你可以寫個middleware專門來出來異常


直接上在下早先的一個回答:

知乎用戶:為什麼說try catch 隱藏了bug,try catch什麼時候用,謝謝解答??

www.zhihu.com圖標

除此之外再多說兩句:

好的設計一定是可簡單應用於大部分常規情況、又支持特殊情況下的擴展,想一點代碼適應所有情況這種想法又偷懶又天真

對於.NET而言除了Exception之外其他的異常信息包裝都是垃圾,反而導致漫山遍野的try...catch


從結果來說其實都可以,但是第二種的話在寫代碼的時候重複的代碼更少,也就是會少犯錯誤,對於心智要求更低,我一般推薦第二種,然後在 Filter 裡面做處理


簡單的處理的話,寫一個actionfilter,不多說,直接上代碼

public class ApiResultFilter : ActionFilterAttribute, IActionFilter
{
public override void OnActionExecuted(ActionExecutedContext context)
{
if (context.HttpContext.Request.IsGetJson())
{

ApiResp& resp = new ApiResp&();
resp.Code = 200;
resp.Message = "請求成功!";
resp.Data = ((ObjectResult)context.Result).Value;
context.Result = new JsonResult(resp);
}

}
}

直接把這個Attribute打在你的action上,就可以在你返回的action實體類上包一層了。

如果需要做類似於abp裡面的throw new UserException(錯誤信息),可以把上面的操作放到全局異常攔截去做。

以前我就是這麼做的,如果現在,我更建議直接使用http的狀態碼,比如錯誤,直接響應500出去


歡迎關注我的公眾號【web開發仔】,分享我認為還可以的短篇入門級的web開發技術,包括JavaScript vue node.js angularhttp://asp.netcore等方面的入門級別的文章和教程.,希望能幫到走在程序員路上的你


要是我的話就會拋異常,而且是在GetFromDB中,全這個異常類型我會從applicationexception派生,命名為友好異常,並且我會在服務層捕獲時不處理這類型異常

而且我會為所有的控制器默認綁定兩個攔截器,一個是異常,一個是普通消息,前者返回的success永遠為false,並且包括message,如果配置允許的話,我會把exception.tostring放在data里一起返回;後者在action執行完畢後檢查action沒有發生異常時執行,將response的content對象包裝在一個success永遠為true的data中返回


通過全局攔截器來實現


我舉得可以複合使用,做個基類或者介面,在裡面加個方法,setErro(Exception ex),方法裡面把ex.message給到message上,然後在try catch的catch裡面寫setErro(ex)。


必然是拋異常。

因為錯誤不僅僅出現在介面,而是可以出現在整個應用的任何一層。如果所有方法都包裝錯誤信息,代碼得多醜?

當你理解了為什麼要拋異常,你就會明白先人是多麼的智慧才能發明出異常機制。就是有時候必要的try catch有點丑。

而使用了異常以後,很多地方就顯得更簡單了。倉儲層找不到指定id數據,拋個notfound異常,上層都不需要判斷返回是否為null,直接讓異常在應用層捕獲然後返回404。

個人建議在異常處理中間件處理異常,這也是官方建議。不過就是中間件中直接操作HttpContext比較麻煩。


推薦閱讀:
相关文章