ASP.NET MVC 4,抛出HttpException vs返回HttpStatusCodeResult？

Question

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

Answer 1

第二个似乎更好,因为它不涉及与第一个例子相比以微成本出现的异常抛出.

Answer 2

作为一个DevOps团队,我们都处于思维模式,在这里投入更多硬件以获得更好的结果总是一个很好的理由.所以我故意忽略了触发.NET异常的微观成本.

如果您正在利用像ApplicationInsights这样的遥测框架,那么只返回状态代码就会给您带来"失败的请求".它不会为您提供任何有用的信息,允许您编译或获取有关失败请求的"原因"的任何信息.

遥测平台期望并且希望你抛出,因为错误遥测通常是围绕.NET异常,所以如果你不抛弃你正在为操作造成问题.

我实际上登陆这里,因为我正在为一个人们喜欢写的项目编写Roslyn分析器和CodeFix,try{} catch { return BadRequest("put_the_reason_here"); }而DevOps或Dev团队在ApplicationInsights的系统遥测中看不到任何有用的东西.

Answer 3

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

据说,如果您对不受支持的网址提出过多请求,则需要再次考虑您的客户.一般情况下,我宁愿抛出异常,因为我不希望在不受支持的URL上收到太多请求,如果确实发生了,那么我想将其作为例外进行记录并调查原因.