【问题标题】:Throwing Exception with inner SecurityException only displays inner exception in ASP.NET MVC使用内部 SecurityException 引发异常仅在 ASP.NET MVC 中显示内部异常
【发布时间】:2012-02-16 11:16:15
【问题描述】:

如果我将以下行添加到 ASP.NET MVC 操作方法

throw new Exception("outer", new SecurityException("inner"));

在黄屏死机上实际显示的错误是内部SecurityException,完全没有提及外部异常。

安全异常

描述:应用程序试图执行的操作不是 安全策略允许的。授予此申请 所需权限请联系您的系统管理员或更改 配置文件中应用程序的信任级别。

异常详细信息:System.Security.SecurityException:内部

来源错误:

在执行过程中产生了一个未处理的异常 当前的网络请求。有关原产地和位置的信息 可以使用下面的异常堆栈跟踪来识别异常。

堆栈跟踪:

[安全异常:内部]

这是预期的行为吗?

外部异常是什么类型似乎并不重要。即使是另一个 SecurityException,也永远不会显示该消息。默认的 SecurityException 错误消息非常模糊,我想抓住它并添加一些更具体的信息。如果我不将原始 SecurityException 作为 innerException 包含在内,这可以正常工作,但理想情况下我想这样做。

【问题讨论】:

  • 我发现这适用于任何内部异常,而不仅仅是安全异常。

标签: asp.net asp.net-mvc exception-handling code-access-security


【解决方案1】:

此行为源自 ASP.NET“核心”,而不是 ASP.NET MVC。不幸的是,错误格式化程序类是内部的,并且消费类型不提供任何扩展点,允许人们在不替换错误报告机制的情况下调整行为。解决方法是用自定义错误页面/视图替换默认的“黄屏死机”页面,在该页面/视图中可以公开自己喜欢的信息。

这正是生产中通常应该做的事情。在您的情况下,这只是意味着您将有一个用于调试的替代版本,而不是使用 ASP.NET 提供的默认版本。

【讨论】:

    【解决方案2】:

    一般来说,你不应该直接抛出异常类/对象,而应该只抛出派生类,例如:

    throw new SecurityException("user should not be allowed to access this method...");
    

    在这种情况下,您在日志或页面中缺少什么?

    如果您使用应用程序全局异常处理程序并使用Log4NetNLog 从那里记录,您应该能够访问从外部到内部的所有异常链,依此类推,具体取决于您如何配置和使用日志记录框架。 IIS / ASP.NET 的黄页可能不完整,但应该会显示堆栈跟踪。

    如果你想从 catch 块中抛出你自己的异常,你可以用这种方式包装来自 catch 的实际异常:

    throw new SecurityException("user should not be allowed...", exc);
    

    编辑:尝试了您的建议,并通过 Log4Net 在文本文件中记录了以下内容:

    System.Security.SecurityException:更明确的异常 ---> System.Security.SecurityException:原始异常在 EDICheckerApp.Program.boom() 在 C:\DEV_RPP\Program.cs:第 45 行
    --- 内部异常堆栈跟踪结束 --- 在 EDICheckerApp.Program.boom() 中 C:\DEV_RPP\Program.cs:第 49 行
    在 EDICheckerApp.Program.Main(String[] args) 中 C:\DEV_RPP\Program.cs:第 27 行

    【讨论】:

    • 试试这个,你就会明白我在说什么:try { throw new SecurityException("original exception"); } catch (SecurityException ex) { throw new SecurityException("更明确的异常", ex); }
    • 是的,我理解,但是尝试使用日志框架转储整个内容,您会在日志文件中得到什么?
    • 在这种情况下,消息主要是给开发者的。我希望提出友好的错误消息,以便开发人员在调试时看到它,而不是用于日志记录,这样他们就会得到任何易于理解的消息,而不是神秘的消息。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2012-03-24
    • 1970-01-01
    • 2023-04-09
    • 2020-05-04
    • 1970-01-01
    • 1970-01-01
    • 2010-09-07
    相关资源
    最近更新 更多