ASP.NET MVC 4，抛出HttpException vs返回HttpStatusCodeResult？
我正在开发一个RESTful服务，我想返回400所有不支持的URL。
我的问题是我应该在何时select方法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"); }
第二个似乎更好，因为它不涉及exception抛出，与第一个例子相比，这是一个微小的成本。
在我看来，您需要首先考虑是否对不受支持的URL进行了请求。 那么你认为这是一个特殊的情况，或者你期望发生？ 如果你认为这是一种特殊情况，那么创build并抛出exception（选项1）。 如果您预计您将收到不受支持的URL的许多请求，请将其视为您应用程序的function并使用方法2。
这就是说，如果您对不受支持的URL有太多请求，则需要再次考虑您的客户。 一般来说，我宁愿抛出一个exception，因为我不希望在不受支持的URL上收到太多的请求，如果发生这种情况，那么我想将它logging为例外，并调查原因。
作为一名DevOps团队，我们都处于思维定势之中，抛出更多的硬件来获得更好的结果总是一个好的原因。 所以我故意忽略了引发.NETexception的微小成本。
如果您正在利用像ApplicationInsights这样的遥测框架，那么只要返回状态代码就可以为您提供“失败的请求”。 它不会给你任何有用的信息，允许你编译或获取有关失败请求的“原因”的任何信息。
遥测平台期望并希望你抛出，因为错误遥测通常是围绕.NETexception，所以如果你不投掷，就会造成操作问题。
我实际上是在这里登陆的，因为我正在编写一个Roslyn分析器和CodeFix的过程，用于一个人们喜欢写的try{} catch { return BadRequest("put_the_reason_here"); } try{} catch { return BadRequest("put_the_reason_here"); }并且DevOps或Dev团队都没有在ApplicationInsights的系统遥测中看到任何有用的信息。
虽然这个问题有点老，但我想我会提出我的意见，因为我遇到了这个问题。
错误是价值。 这适用于HttpException （当unthrown）以及HttpStatusCodeResult。 但是，抛出exception会创build新的代码path，这些代码path远离同事，可能是一个比您的执行上下文更高的执行上下文，必须给出这些代码path将被传递给他们的文档，恕不另行通知。 然而，价值观告诉你，通过他们的types你需要知道的一切。 您可以在预期的执行path中使用它们的types来判断是否发生了错误，并查找与该错误相关的信息并logging下来。
我有时使用（轻度扩展）的Exception ，而不把它们扔到下一个执行上下文来提取David Rodriguez提到的有用的debugging信息。 从来没有任何借口将抛出的exception交给上面的执行上下文，而这些exception实际上并不例外，这只适用于实际上不在你的代码处理能力之外的事情（ StackOverflowException ，其他致命的系统exception等）。
在一个networking应用程序中，比如你运行的任何MVC服务，抛出exception的性能损失都是毫无意义的。 可维护性的语义和效果不是。
networking错误是值，你应该像这样处理它们。
