59

我正在开发一个 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");
}
4

5 回答 5

50

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

于 2013-06-17T13:24:47.263 回答
13

作为DevOps团队中的一员，我们都处于这样一种心态，即投入更多的硬件来获得更好的结果总是一个好的原因。所以我故意忽略了触发 .NET 异常的微成本。

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

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

我实际上来到了这里，因为我正在为人们喜欢编写的项目编写Roslyntry{} catch { return BadRequest("put_the_reason_here"); }分析器和 CodeFix，而 DevOps 或开发团队都认为 ApplicationInsights 中的系统遥测没有任何用处。

于 2015-11-25T14:47:09.440 回答
9

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

也就是说，如果您期望对不受支持的 URL 有太多请求，您将需要再次考虑客户的问题。一般来说，我更愿意抛出异常，因为我不希望在不受支持的 URL 上收到太多请求，如果确实发生了，我想将其记录为异常并调查原因。

于 2014-03-17T18:44:58.427 回答
1

虽然这个问题有点老了，但自从我遇到这个问题以来，我想我会给出我的意见。

错误是价值。这适用于HttpException（未抛出时）以及HttpStatusCodeResult. 但是，抛出的异常会创建新的代码路径，这些代码路径对您的同事隐藏，这可能是比您的执行上下文更高的一个执行上下文，并且必须提供这些代码路径将在不通知的情况下传递给他们的文档。然而，值通过它们的类型告诉你你需要知道的一切。您可以在预期的执行路径中使用它们的类型来判断是否发生了错误，并找到与该错误相关的信息并记录它。

我有时会使用 (lightly extended)Exception而不将它们扔到下一个执行上下文中来提取 David Rodriguez 提到的有用的调试信息。没有任何借口可以将抛出的异常交给您上面实际上并非异常的执行上下文，并且这只适用于实际上超出您的代码处理能力的事情（StackOverflowException其他致命系统异常等）。

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

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

于 2016-01-08T19:42:30.163 回答
0

您将在无法返回 actionResult 的代码位置抛出异常，例如在控制器构造函数中。

于 2021-11-05T13:46:31.687 回答