asp.net-mvc ASP.NET MVC，抛出 HttpException 还是返回 HttpStatusCodeResult？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/17148554/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
ASP.NET MVC, throw HttpException vs return HttpStatusCodeResult?
提问by Rosdi Kasim
I am developing a RESTful service and I want to return 400 for all unsupported URLs.
我正在开发一个 RESTful 服务，我想为所有不受支持的 URL 返回 400。
My question is when should I choose method 1 over method 2 and vice-versa..
我的问题是我什么时候应该选择方法 1 而不是方法 2，反之亦然。
//method 1
public ActionResult Index()
{
//The url is unsupported
throw new HttpException(400, "Bad Request");
}
This one seems to be better?
这个好像更好？
//method 2
public ActionResult Index()
{
//The url is unsupported
return new HttpStatusCodeResult(HttpStatusCode.BadRequest, "Bad Request");
}
采纳答案by David Rodrigues
Being in a DevOpsteam, we are all in the mind-set where throwing more hardware at something to get a slightly better result is always a good cause. So I'm intentionally ignoring the micro-cost of firing a .NET exception.
作为DevOps团队中的一员，我们都认为投入更多硬件以获得更好的结果始终是一个很好的理由。所以我故意忽略了触发 .NET 异常的微成本。
If you're leveraging a telemetry framework like ApplicationInsightsthen just returning the status code gives you nothing more than a "failed request". It doesn't give you any useful information that allows you to either compile or get any information on the "why" of the failed request.
如果您正在利用ApplicationInsights 之类的遥测框架，那么仅返回状态代码只会给您一个“失败的请求”。它不会为您提供任何有用的信息，使您可以编译或获取有关失败请求“原因”的任何信息。
Telemetry platforms expect and want you to throw, because error telemetry is usually around .NET exceptions, so if you're not throwing you're creating a problem for operations.
遥测平台期望并希望您抛出，因为错误遥测通常围绕 .NET 异常，因此如果您不抛出，就会为操作带来问题。
I actually landed here, because I'm in the process of writing a Roslynanalyser and CodeFix for a project where folks love to write try{} catch { return BadRequest("put_the_reason_here"); }and neither DevOps or the Dev teams see nothing useful in the system telemetry in ApplicationInsights.
我实际上来到了这里，因为我正在为一个人们喜欢编写的项目编写Roslyn分析器和 CodeFix，try{} catch { return BadRequest("put_the_reason_here"); }而 DevOps 或开发团队都认为 ApplicationInsights 中的系统遥测没有任何用处。
回答by Darin Dimitrov
The second seems better as it doesn't involve exception throwing which comes at a micro-cost compared to the first example.
第二个看起来更好，因为它不涉及异常抛出，与第一个示例相比，这是一个微成本。
回答by Suneet Nangia
In my view you need to consider first if a request is made to the unsupported URLs. Then do you think of it is an exceptional situation or you expect that to happen? If you think of it as an exceptional situation then create and throw an exception (option 1). If you are expecting that you will receive many requests on the unsupported URL then treat it as a function of your application and use method 2.
在我看来，您首先需要考虑是否向不受支持的 URL 发出请求。那么您认为这是一种特殊情况还是您希望这种情况发生？如果您将其视为异常情况，则创建并抛出异常（选项 1）。如果您希望在不受支持的 URL 上收到许多请求，请将其视为您的应用程序的功能并使用方法 2。
That's said you will need to think about your clients' again if you are expecting too many requests on the unsupported URLs. In general I would prefer to throw an exception as I don't expect to receive too many requests on the unsupported URLs, and if it does happen then I would like to log it as an exception and investigate the reason.
也就是说，如果您期望对不受支持的 URL 有太多请求，您将需要再次考虑您的客户。一般来说，我更愿意抛出异常，因为我不希望在不受支持的 URL 上收到太多请求，如果确实发生了，那么我想将其记录为异常并调查原因。
回答by humanoidanalog
Although this question is a bit old I figured I'd give my input since I came across this.
虽然这个问题有点老了，但我想自从我遇到这个问题后我会给出我的意见。
Errors are values. This goes for an HttpException(when unthrown) as well as an HttpStatusCodeResult. Thrown exceptions, however, create new code paths that are hidden away from your coworkers that may be one execution context higher up than yours and have to be given documentation that these code paths will be passed to them without notice. Values, however, tell you everything you need to know through their type. You can use their type in the expected execution path to tell whether an error has occured as well as find associated information with that error and log it.
错误就是价值。这适用于HttpException（未抛出时）和HttpStatusCodeResult. 然而，抛出的异常会创建新的代码路径，这些代码路径对您的同事隐藏，这些代码路径可能比您的执行上下文更高，并且必须提供文档说明这些代码路径将在没有通知的情况下传递给他们。然而，值通过它们的类型告诉你你需要知道的一切。您可以在预期的执行路径中使用它们的类型来判断是否发生了错误，以及查找与该错误相关的信息并记录下来。
I sometimes use (lightly extended) Exception's without throwing them to the next execution context to extract the useful debug information that David Rodriguez mentioned. There's never an excuse to be handing thrown exceptions to execution contexts above you that aren't actually exceptional, and this only really applies to things that are actually outside of your code's ability to handle (StackOverflowException, other fatal system exceptions, etc).
我有时会使用（稍微扩展）Exception's 而不将它们扔到下一个执行上下文来提取 David Rodriguez 提到的有用调试信息。从来没有任何借口将抛出的异常交给你上面的执行上下文，这些异常实际上并不是异常的，这仅适用于实际上超出代码处理能力范围的事情（StackOverflowException、其他致命的系统异常等）。
In a networked application, such as whatever MVC service you're running, the performance penalty from throwing exceptions is meaningless. The semantics and effects on maintainability, are not.
在网络应用程序中，例如您正在运行的任何 MVC 服务，抛出异常的性能损失是没有意义的。语义和对可维护性的影响不是。
Network errors are values, and you should handle them like so.
网络错误是值，您应该像这样处理它们。
