【问题标题】:Advantages of [HandleError] over Application_Error[HandleError] 相对于 Application_Error 的优势
【发布时间】:2012-05-08 10:47:36
【问题描述】:

我知道 SO 中有很多关于 ASP.NET MVC 中的错误处理 的问题。

我明白了,大多数人都试图通过三种方式实现目标:

  1. 创建BaseController 并覆盖OnException 方法

  2. 使用[HandleError] 或自定义异常过滤器。

  3. Application_Error global.asax.cs 中的事件

前两种方法不能处理所有异常,它们只能处理由操作方法/过滤器引发的异常,因此显然第三种方法将是全局异常处理程序的最佳方法。

我的问题是为什么我应该采用[HandleError] 方法?它带来了哪些我无法通过Application_Error 的好处?

最后,我想在 MVC 应用程序中认真对待 customErrors 部分吗?

注意:我的要求是正常的。每当发生异常时,记录它并返回自定义错误页面。自定义错误页面可能会根据状态代码而改变。

【问题讨论】:

    标签: asp.net-mvc error-handling


    【解决方案1】:

    最明显的是[HandleError] 允许您在不同的控制器和操作中以不同的方式处理错误。它比 Application_Error 处理程序中的某种 switch 语句要优雅得多。

    另一个好处是[HandleError] 仍然可以访问控制器以及它附带的所有 MVC 优点,因此您仍然可以返回 View 或调用其他操作。一旦你放弃Application_Error,你就失去了ControllerContext,除了重定向之外你别无选择。

    【讨论】:

    • 我看不出为什么有人想在不同的控制器和操作中以不同的方式处理错误。好的,如果我在 [HandleError] 中执行该逻辑,那么我想再次在 global.asax 中执行此操作,对吗?
    • 移动设备的不同错误页面?为用户提供个性化的错误页面? ajax请求的HTML片段?损坏图像链接的自定义错误图像?访问某些控制器的禁止错误页面?不难想出以不同方式处理错误的原因。
    猜你喜欢
    • 2017-03-19
    • 2010-12-23
    • 2015-07-23
    • 2011-02-26
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多