Throwing an Exception with an Internal SecurityException Displays Only an Internal Exception in ASP.NET MVC

Question

If I add the following line to the ASP.NET MVC action method

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

the error that actually appears on the yellow screen of death is an internal SecurityException, absolutely not mentioning an external exception.

SecurityException

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

Exception Details: System.Security.SecurityException: internal

Source Error:

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

Stack trace:

[SecurityException: internal]

Is this the expected behavior?

It doesn't seem to matter which type is an external exception. Even if it is another SecurityException, the message is never displayed. The default SecurityException error message is so vague that I want to catch it and add more specific information. This works fine if I do not include the original SecurityException as an internal exception, but ideally I would like to do this.

Answer 1

This behavior occurs in the "core" of ASP.NET, and not in ASP.NET MVC. Unfortunately, error formatting classes are internal, and consumption types do not provide any extension points that would allow you to change behavior without replacing the error message mechanism. A workaround is to replace the default "yellow screen of death" page on the custom error page / view, which reveals the information you prefer.

This is exactly what you usually need to do for production. In your case, this simply means that you will have an alternative version for debugging instead of using the default ASP.NET provided.

Answer 2

in general, you should never throw an Exception class / object directly, but only derivatives, for example:

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

in such a situation, what do you miss in the magazine or on the page?

if you use the global application exception handler and you log in there using Log4Net or NLog , you must have access to the entire exception chain from external to internal, and so on, depending on how you configure and use the framework log. The yellow IIS / ASP.NET page may be incomplete, but it should show a stack trace anyway.

if you want to throw your own exception from the catch block, you are carrying the actual exception coming from the catch this way:

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

Edit : I tried what you suggested and got LogLogNet in a text file:

System.Security.SecurityException: the more obvious exception ---> System.Security.SecurityException: the original exception in EDICheckerApp.Program.boom () in C: \ DEV_RPP \ Program.cs: line 45
--- The end of the internal trace of the exception stack is in EDICheckerApp.Program.boom () in C: \ DEV_RPP \ Program.cs: line 49
in EDICheckerApp.Program.Main (String [] args) in C: \ DEV_RPP \ Program.cs: line 27