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响应类型比较

回答

相关问题