blocks|key|186127|text|第二个看起来更好，因为它不涉及异常抛出，与第一个例子相比，抛出异常的代价很小。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|186128|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

The second seems better as it doesn't involve exception throwing which comes at a micro-cost compared to the first example.

blocks|key|3015225|text|在我看来，您需要首先考虑是否向不支持的URL发出请求。那么，你认为这是一种例外情况，还是你预计会发生这种情况？如果您认为这是一个异常情况，那么创建并抛出一个异常(选项1)。如果您期望在不受支持的URL上收到许多请求，则将其视为您的应用程序的函数并使用方法2。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3015226|也就是说，如果你期望在不支持的URL上有太多的请求，你需要再次考虑你的客户。一般来说，我更喜欢抛出异常，因为我不希望在不支持的URL上收到太多请求，如果确实发生了，我会将其记录为异常并调查原因。|3015227|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

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.

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.

blocks|key|2802904|text|作为DevOps团队中的一员，我们都有这样的想法，即在某些事情上投入更多的硬件来获得稍微更好的结果总是一个好的理由。所以我故意忽略触发.NET异常的微成本。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|2802905|如果你正在使用像ApplicationInsights这样的遥测框架，那么仅仅返回状态码就只会给你一个“失败的请求”。它不会为您提供任何有用的信息，使您能够编译或获取有关失败请求的“原因”的任何信息。|2802906|遥测平台期望并希望您抛出异常，因为错误遥测通常与.NET异常有关，所以如果您不抛出，就会给操作带来问题。|2802907|我之所以来到这里，是因为我正在为一个项目编写Roslyn分析器和CodeFix，在这个项目中，人们喜欢编写try{}+catch+{+return+BadRequest("put_the_reason_here");+}，而DevOps和开发团队在ApplicationInsights的系统遥测中都看不到任何有用的东西。|style|CODE|2802908|entityMap|0|LINK|mutability|MUTABLE|url|https://en.wikipedia.org/wiki/DevOps|1|https://azure.microsoft.com/en-gb/services/application-insights/|2|https://en.wikipedia.org/wiki/.NET_Compiler_Platform^0|2|6|0|0|8|J|1|0|0|1H|1L|M|6|2|0^^$0|@$1|2|3|4|5|6|7|X|8|@]|9|@$A|Y|B|Z|1|10]]|C|$]]|$1|D|3|E|5|6|7|11|8|@]|9|@$A|12|B|13|1|14]]|C|$]]|$1|F|3|G|5|6|7|15|8|@]|9|@]|C|$]]|$1|H|3|I|5|6|7|16|8|@$A|17|B|18|J|K]]|9|@$A|19|B|1A|1|1B]]|C|$]]|$1|L|3|-4|5|6|7|1C|8|@]|9|@]|C|$]]]|M|$N|$5|O|P|Q|C|$R|S]]|T|$5|O|P|Q|C|$R|U]]|V|$5|O|P|Q|C|$R|W]]]]

Being in a <a href="https://en.wikipedia.org/wiki/DevOps" rel="noreferrer">DevOps</a> team, 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.

If you're leveraging a telemetry framework like <a href="https://azure.microsoft.com/en-gb/services/application-insights/" rel="noreferrer">ApplicationInsights</a> then 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.

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.

I actually landed here, because I'm in the process of writing a <a href="https://en.wikipedia.org/wiki/.NET_Compiler_Platform" rel="noreferrer">Roslyn</a> analyser and CodeFix for a project where folks love to write <code>try{} catch { return BadRequest("put_the_reason_here"); }</code> and neither DevOps or the Dev teams see nothing useful in the system telemetry in ApplicationInsights.

blocks|key|3015291|text|虽然这个问题有点老了，但我想我应该给出我的意见，因为我遇到了这个问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3015292|错误是值。这适用于HttpException+(未抛出时)和HttpStatusCodeResult。然而，抛出的异常会创建对同事隐藏的新代码路径，这些代码路径可能是比您的执行上下文更高的执行上下文，并且必须提供文档，说明这些代码路径将在没有通知的情况下传递给他们。但是，值通过它们的类型告诉您需要知道的一切。您可以在预期的执行路径中使用它们的类型来判断是否发生了错误，并查找与该错误相关的信息并将其记录下来。|offset|length|style|CODE|3015293|我有时会使用(略微扩展的)Exception而不把它们扔到下一个执行上下文中去提取David+Rodriguez提到的有用的调试信息，从来没有借口把抛出的异常抛给你上面的执行上下文，而这些异常实际上并不是你的代码所能处理的(StackOverflowException，其他致命的系统异常，等等)。|3015294|在网络应用程序中，例如您正在运行的任何MVC服务，抛出异常所带来的性能损失是毫无意义的。语义和对可维护性的影响则不是。|3015295|网络错误就是值，您应该这样处理它们。|3015296|entityMap^0|0|9|D|U|K|0|D|9|34|M|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@$D|R|E|S|F|G]|$D|T|E|U|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|V|8|@$D|W|E|X|F|G]|$D|Y|E|Z|F|G]]|9|@]|A|$]]|$1|J|3|K|5|6|7|10|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|11|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|12|8|@]|9|@]|A|$]]]|O|$]]

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 <code>HttpException</code> (when unthrown) as well as an <code>HttpStatusCodeResult</code>. 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. 

I sometimes use (lightly extended) <code>Exception</code>'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 (<code>StackOverflowException</code>, other fatal system exceptions, etc). 

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.

Network errors are values, and you should handle them like so.

blocks|key|3015333|text|您将在无法返回actionResult的代码位置引发异常，例如在控制器构造函数中。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3015334|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

you would throw an exception in code locations that cannot return an actionResult, such as in a controller constructor.

I am developing a RESTful service and I want to return 400 for all unsupported URLs.

My question is when should I choose method 1 over method 2 and vice-versa..

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

This one seems to be better?

<pre><code>//method 2
public ActionResult Index()
{
 //The url is unsupported
 return new HttpStatusCodeResult(HttpStatusCode.BadRequest, "Bad Request");
}
</code></pre>

ASP.NET MVC, throw HttpException vs return HttpStatusCodeResult?

DevOps

我正在开发一个RESTful服务，我想为所有不支持的URL返回400。我的问题是，什么时候我应该选择方法1而不是方法2，反之亦然。//method 1public ActionResult Index(){    //The url is unsupported    throw new HttpException(4...

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

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

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

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

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