我认为@GlennBlock 在技术上是错误的。抛出 anHttpResponseException
与返回 没有任何明显不同HttpResponseMessage
。
以下是源代码提供的 ASP.NET Web API 中使用的模式:
try
{
return await SendAsyncCore(request, cancellationToken);
}
catch (HttpResponseException httpResponseException)
{
return httpResponseException.Response;
}
catch (Exception exception)
{
exceptionInfo = ExceptionDispatchInfo.Capture(exception);
}
在管道中的这一点上,如果您抛出 anHttpResponseException
它会被视为与返回 an HttpResponseMessage
... 它的行为完全相同。
您会注意到的一件事是,在使用 Visual Studio 进行调试时,调试器会在抛出异常时中断HttpResponseException
(因为用户代码中没有发生捕获)。如果这是在您网站的正常运行中经常发生的预期错误,那么这会变得非常烦人!在这种情况下,您可能希望返回带有HttpResponseMessage
.
另一方面,如果这是一个理论上不应该发生的奇怪错误,那么您希望调试器发出警报。您不希望错误被悄悄地忽略。您想了解它,以便理论上可以修复它。在这种情况下,抛出HttpResponseException
更有意义。
关于我能说的唯一其他区别是,投掷 anHttpResponseException
可以让你用IExceptionFilter
. 与将操作过滤器或授权过滤器应用于方法或控制器的方式类似,您可以应用异常过滤器来处理所有异常。也许您想将它们记录到您的数据库中。应用属性过滤器显然比在每个操作方法中都编写 try/catch 要容易得多。
在这种情况下,抛出异常实际上比简单地返回响应做更多的工作并且花费更长的时间。但这是一个区别。
AnIHttpActionResult
用于创建HttpResponseMessage
. 将其视为一个HttpResponseMessage
工厂,您可以在其中编写一次并通过多种操作方法使用它。在这种情况下,您可以HttpResponseException
从IHttpActionResult
. 这与直接从动作中执行没有任何不同。