ASP.NET MVC，抛出HttpException与返回HttpStatusCodeResult吗？

Question

我正在开发RESTful服务，并且我想为所有不支持的URL返回400。

我的问题是[[我何时应该选择方法1而不是方法2，反之亦然。

//method 1
public ActionResult Index()
{
    //The url is unsupported
    throw new HttpException(400, "Bad Request");
}

这似乎更好？
//method 2
public ActionResult Index()
{
    //The url is unsupported
    return new HttpStatusCodeResult(HttpStatusCode.BadRequest, "Bad Request");
}

Answer 1

在DevOps团队中，我们所有人都处于思维定势，在其中投入更多的硬件以获得更好的结果始终是一个好理由。因此，我故意忽略了触发.NET异常的微小代价。

[如果您使用的是ApplicationInsights之类的遥测框架，那么仅返回状态代码就不会给您带来“失败的请求”。它没有提供任何有用的信息，使您无法编译或获取有关失败请求“原因”的任何信息。

遥测平台期望并希望您抛出异常，因为错误遥测通常围绕.NET异常，因此，如果不抛出异常，则会给操作造成问题。

我实际上是在这里着陆的，因为我正在为一个人们喜欢写Roslyn的项目编写try{} catch { return BadRequest("put_the_reason_here"); }分析器和CodeFix，而DevOps或Dev团队都没有发现ApplicationInsights中的系统遥测没有任何用处。

Answer 2

第二个似乎更好，因为它不涉及引发异常，与第一个示例相比，该抛出的开销很小。

Answer 3

我认为您需要首先考虑是否对不支持的URL进行了请求。那您认为这是一种例外情况还是您希望这种情况发生？如果您认为这是一种例外情况，请创建并引发异常（选项1）。如果期望收到不支持的URL上的许多请求，则将其视作您的应用程序的功能，并使用方法2。

就是说，如果您期望对不支持的URL的请求过多，则需要重新考虑客户的需求。通常，我希望抛出一个异常，因为我不希望在不支持的URL上收到太多请求，如果确实发生了，那么我想将其记录为异常并调查原因。

Answer 4

尽管这个问题有点老了，但自从碰到这个问题后，我认为我会提供自己的意见。

错误是值。这适用于HttpException（当被抛出时）和HttpStatusCodeResult。但是，抛出的异常会创建对您的同事隐藏的新代码路径，这些代码路径可能是比您更高的执行上下文，并且必须获得文档说明这些代码路径将被传递给他们，而不另行通知。但是，值会告诉您所有需要了解的类型。您可以在预期的执行路径中使用它们的类型来判断是否已发生错误，以及查找与该错误相关的信息并进行记录。

我有时使用（略微扩展）Exception，而没有将它们扔到下一个执行上下文中以提取David Rodriguez提到的有用的调试信息。从来没有理由将抛出的异常移交给您之上的执行上下文，这些异常实际上并不例外，并且这仅适用于实际上超出了代码处理能力的事物（StackOverflowException，其他致命系统异常等） 。

在网络应用程序中，例如您正在运行的任何MVC服务，抛出异常所带来的性能损失都是毫无意义的。语义和对可维护性的影响不是。

网络错误是值，应该像这样处理它们。