Web API 2響應類型比較

我這樣編碼，它對單元測試很好。Web API 2響應類型比較

[ResponseType(typeof(bool))] 
public async Task<IHttpActionResult> Send() 
{ 
    try 
    { 
     await dosomething(); 

     return Ok(true); 
    } 
    catch (Exception ex) 
    { 
     return InternalServerError(ex); 
    } 
}

但有人建議嘗試捕捉是多餘的，因爲Web API處理已經和他提出了這樣的代碼：

public async Task<bool> Send() 
{ 
    await dosomething(); 

    return true; 
}

我只是想知道哪一個是更好的選擇。

來源

2016-04-27 wesley Wang

像這樣的異步編程，我會建議第一個選項最適合當你需要調試你的工作和捕捉異常。 Web API不會自動處理，我不會同意這一點。嘗試在兩種情況下拋出異常來測試它。 – Derek

我認爲額外的try catch會導致它在性能方面做更多的工作，如果有一個異常它會在這裏被捕獲並且不會傳播到Web API全局級別。我猜Web API已經處理了未捕獲的異常，所以仍然會返回錯誤500。無論如何，我會盡量產生一個例外，並檢查出來。謝謝 –

我只是在談論何時需要調試錯誤。 – Derek

你應該好好Exception Handling in ASP.NET Web API

讀如果一個Web API控制器拋出一個未捕獲的異常，會發生什麼？通過默認值，大多數異常會轉換爲HTTP響應，其中狀態碼爲500，內部服務器錯誤。

也Global Error Handling in ASP.NET Web API 2

至於建議，你應該儘量保持你的控制器瘦儘可能提到的建議。像原始代碼一樣的錯誤處理只會導致代碼的重複，以及開發人員需要注意的不必要的問題。開發人員應該關注核心問題，而不是交叉問題。通過只專注於核心關注上面的代碼將是這樣的：在網絡API

[ResponseType(typeof(bool))] 
public async Task<IHttpActionResult> Send() { 
    await dosomething(); 
    return Ok(true); 
}

錯誤處理被認爲是一個橫切關注點，應在管線另置一處，因此開發商不需要關注跨領域關切。

來源

2016-04-28 02:48:48 Nkosi

我剛剛意識到在Web API配置中註冊了一個異常處理程序，因此try catch是冗餘的。感謝您的幫助！ –

Web API 2響應類型比較

回答

相關問題