6

如果我下面的行添加到ASP.NET MVC操作方法與內拋出:SecurityException引發異常僅在ASP.NET MVC顯示內部異常

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

那就是死亡的黃色屏幕上實際顯示的錯誤是內部SecurityException,絕對沒有提及外部異常。

SecurityException

Description: The application attempted to perform an operation not allowed by the security policy. To grant this application the required permission please contact your system administrator or change the application's trust level in the configuration file.

Exception Details: System.Security.SecurityException: inner

Source Error:

An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.

Stack Trace:

[SecurityException: inner]

這是預期的行爲嗎?

外部異常的類型似乎並不重要。即使它是另一個SecurityException,也不會顯示消息。默認的SecurityException錯誤信息非常模糊,我想抓住它並添加一些更具體的信息。如果我不包含原始的SecurityException作爲innerException,但是理想情況下我想這樣做,這工作正常。

+0

我看到任何內部異常都是如此,而不僅僅是securityexception。 – 2017-10-27 16:30:23

回答

-1

一般你不應該拋出異常類/對象直接,但只有那些得到的,例如:在這樣的情況下你這是在日誌或頁面丟失

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

,如果你使用的應用程序全局異常處理,你從那裏記錄與任何Log4NetNLog你應該能夠從外部訪問所有的異常鏈內等取決於你如何配置和使用日誌框架。 IIS/ASP.NET的黃頁可能不完整,但應該顯示堆棧跟蹤。

,如果你想從一個catch塊拋出自己的例外您纏繞實際的異常從抓進來的是這樣的:

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

編輯:嘗試你的建議,並得到了在下面登錄Log4Net的文本文件:

System.Security.SecurityException: more explicit exception ---> System.Security.SecurityException: original exception at EDICheckerApp.Program.boom() in C:\DEV_RPP\Program.cs:line 45
--- End of inner exception stack trace --- at EDICheckerApp.Program.boom() in C:\DEV_RPP\Program.cs:line 49
at EDICheckerApp.Program.Main(String[] args) in C:\DEV_RPP\Program.cs:line 27

+1

試試這個,你會明白我在說什麼:嘗試 { }拋出新的SecurityException(「原始異常」); (「更明確的例外」,前); } – 2012-02-16 11:38:26

+0

是的我明白,但嘗試轉儲與日誌框架整個事情,你在日誌文件中得到什麼? – 2012-02-16 11:40:36

+1

在這種情況下,該消息主要針對開發人員。我想提出友好的錯誤消息,以便開發人員在調試時看到它,而不是記錄,因此他們得到任何容易理解的消息,而不是一個神祕的消息。 – 2012-02-16 11:47:31

5

此行爲起源於ASP.NET「核心」,而不是ASP.NET MVC。不幸的是,錯誤格式化程序類是內部的,消費類型不提供任何擴展點,這些擴展點允許在不更換錯誤報告機制的情況下調整行爲。解決方法是用自定義錯誤頁面/視圖替換默認的「死亡黃頁」頁面,在該頁面/視圖中顯示人們喜歡的信息。

這正是人們通常應該爲生產做的。在你的情況下,這意味着你將有一個替代版本的調試,而不是使用ASP.NET提供的默認值。