ASP.NET MVC，抛出HttpException vs返回HttpStatusCodeResult？
我正在开发一个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");
}回答 5
Stack Overflow用户
发布于 2015-11-25 22:47:09
作为DevOps团队中的一员，我们都有这样的想法，即在某些事情上投入更多的硬件来获得稍微更好的结果总是一个好的理由。所以我故意忽略触发.NET异常的微成本。
如果你正在使用像ApplicationInsights这样的遥测框架，那么仅仅返回状态码就只会给你一个“失败的请求”。它不会为您提供任何有用的信息，使您能够编译或获取有关失败请求的“原因”的任何信息。
遥测平台期望并希望您抛出异常，因为错误遥测通常与.NET异常有关，所以如果您不抛出，就会给操作带来问题。
我之所以来到这里，是因为我正在为一个项目编写Roslyn分析器和CodeFix，在这个项目中，人们喜欢编写try{} catch { return BadRequest("put_the_reason_here"); }，而DevOps和开发团队在ApplicationInsights的系统遥测中都看不到任何有用的东西。
Stack Overflow用户
发布于 2013-06-17 21:24:47
第二个看起来更好，因为它不涉及异常抛出，与第一个例子相比，抛出异常的代价很小。
Stack Overflow用户
发布于 2014-03-18 02:44:58
在我看来，您需要首先考虑是否向不支持的URL发出请求。那么，你认为这是一种例外情况，还是你预计会发生这种情况？如果您认为这是一个异常情况，那么创建并抛出一个异常(选项1)。如果您期望在不受支持的URL上收到许多请求，则将其视为您的应用程序的函数并使用方法2。
也就是说，如果你期望在不支持的URL上有太多的请求，你需要再次考虑你的客户。一般来说，我更喜欢抛出异常，因为我不希望在不支持的URL上收到太多请求，如果确实发生了，我会将其记录为异常并调查原因。
https://stackoverflow.com/questions/17148554
复制相似问题
腾讯云开发者
