在 ASP.NET MVC 中，我应该重定向到错误页面还是简单地返回错误视图？答案

【问题标题】：In ASP.NET MVC Should I Redirect to an Error Page or Simply Return an Error View?在 ASP.NET MVC 中，我应该重定向到错误页面还是简单地返回错误视图？
【发布时间】：2012-01-01 11:37:58
【问题描述】：

当我问这个问题时，我主要考虑的是错误的参数。参数在哪里：

int
string 为空或空格
模型绑定对象缺少关键属性
“id not found errors”（一个“有效的”整数 id 被传递给操作，但没有对应的数据库记录）

以下是我所说的两种错误处理场景：

public ActionResult GoToError(int value, string name)
{
    if (value <= 0 || string.IsNullOrWhiteSpace(name))
    {
        // Parameter(s) not meeting basic conditions
        TempData["ErrorMessage"] = "Invalid parameters";
        return RedirectToAction("Index", "Error");
    }

    return View();
}

public ActionResult ReturnView(int value, string name)
{
    if (value <= 0 || string.IsNullOrWhiteSpace(name))
    {
        // Parameter(s) not meeting basic conditions
        ViewData["ErrorMessage"] = "Invalid parameters";
        return View("Error");
    }

    return View();
}

【问题讨论】：

标签： c# asp.net asp.net-mvc-3 error-handling

【解决方案1】：

在 RESTFul 应用程序中，您应该返回视图并设置相应的 HTTP 状态代码（401、403、404、500，...）。当您重定向时，这意味着状态代码 200 并为错误页面返回状态代码 200 没有意义。这是我用来处理错误的technique。当您可以订阅不同的状态代码时，这也非常适用于 AJAX。例如，假设您有一个经过身份验证的站点，登录用户可以在其中执行 AJAX 请求。在某些不活动之后，如果您的服务器没有返回正确的状态代码（在这种情况下为 401），他们的会话可能会过期，并且当他们需要执行一些 AJAX 请求时，客户端脚本将很难理解和处理该场景。

【讨论】：

【解决方案2】：

在 ASP.NET 中正确处理错误简直是噩梦般的难。

如果您遵循网络的意图：

对于任何无法从错误中恢复的错误，您应该返回错误结果，例如 400 错误请求、404 资源未找到等。这包括 4xx 范围内的大部分错误。

对于将导致 500 错误的未处理异常的应用程序错误，正确的解决方案是发出 302 重定向到正确返回 500 状态代码的错误页面。

正如@Darin Dimitrov 所说，在 RESTful 应用程序中，您永远不应该为任何应该始终明确返回结果的东西发出重定向。

【讨论】：

【解决方案3】：

有不同的场景，需要以不同的方式处理：

对于您没有预料到的完全意外错误，我建议让异常冒泡并在Controller.OnException(...) method 和/或asp.net custom error pages 中处理它
对于常见的预期错误，例如用户提供错误输入，返回视图并显示通过ModelState.Errors 传递的错误是正确的
如果打算通过 AJAX/Javascript/作为服务调用该操作，您需要协调您发回的内容。它可能是自定义 JSON 对象或特定视图。

根据您发布的内容，我无法将天气归类为“预期”或“未预期”。主要问题是，这些调用的客户希望如何处理它们？

【讨论】：