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

第二个似乎更好，因为它不涉及与第一个例子相比以微观成本抛出的异常抛出。

Answer 2

在一个DevOps团队中，我们都处于思维模式中，为了获得更好的结果而投入更多的硬件总是一个很好的理由。所以我故意忽略了触发.NET异常的微观成本。

如果您正在利用像ApplicationInsights这样的遥测框架，那么只需返回状态代码就会给您带来“失败的请求”。它没有为您提供任何有用的信息，允许您编译或获取有关失败请求的“原因”的任何信息。

遥测平台期望并且希望你抛出，因为错误遥测通常是围绕.NET异常，所以如果你没有抛弃你正在为操作造成问题。

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

Answer 3

在我看来，您需要先考虑是否请求不受支持的网址。那么你认为这是一种特殊情况还是你希望这种情况发生？如果您将其视为特殊情况，则创建并抛出异常（选项1）。如果您希望在不受支持的URL上收到许多请求，请将其视为应用程序的功能并使用方法2.

如果您对不受支持的网址提出过多请求，则表示您需要再次考虑您的客户。一般情况下，我宁愿抛出异常，因为我不希望在不受支持的URL上收到太多请求，如果确实发生了，那么我想将其作为例外进行记录并调查原因。

Answer 4

虽然这个问题有点旧，但我想我会在发现这个问题后给出我的意见。

错误是价值观。这适用于HttpException（不作为时）和HttpStatusCodeResult。但是，抛出的异常会创建隐藏在您的同事之外的新代码路径，这些代码路径可能是比您更高的一个执行上下文，并且必须提供文档，这些代码路径将在不事先通知的情况下传递给它们。但是，值告诉您需要通过其类型了解的所有内容。您可以在预期的执行路径中使用它们的类型来判断是否发生了错误，并查找与该错误相关的信息并进行记录。

我有时使用（轻度扩展）Exception而不将它们抛到下一个执行上下文中，以提取David Rodriguez提到的有用的调试信息。从来没有借口将抛出的异常交给你上面的执行上下文，这些异常实际上并不例外，这只适用于那些实际上超出代码处理能力的事情（StackOverflowException，其他致命的系统异常，等等）。

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

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

ASP.NET MVC 4，抛出HttpException vs返回HttpStatusCodeResult？

4 个答案: