6

Se posso aggiungere la seguente riga a un metodo di azione ASP.NET MVCLanciare Eccezione con SecurityException interno visualizza solo eccezione interna in ASP.NET MVC

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

l'errore che viene effettivamente visualizzato sullo schermo giallo della morte è la SecurityException interna senza assolutamente menzionare l'eccezione esterna.

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]

È questo comportamento previsto?

Non sembra importare quale sia l'eccezione esterna. Anche se è un'altra SecurityException, il messaggio non viene mai visualizzato. Il messaggio di errore predefinito SecurityException è talmente vago che voglio prenderlo e aggiungere alcune informazioni più specifiche. Funziona bene se non includo SecurityException originale come innerException, ma idealmente mi piacerebbe farlo.

+0

Sto vedendo questo è vero per qualsiasi eccezione interna, non solo securityexception. –

risposta

-1

, in generale, non si dovrebbe mai tiro classe Exception/object direttamente, ma derivato solo quelli, per esempio:

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

in una situazione come questa, cosa stai perdendo nel log o nella pagina?

se si utilizza un gestore di eccezioni globale delle applicazioni e si accede da lì sia con Log4Net o NLog si dovrebbe essere in grado di accedere a tutta la catena eccezione da esterno a interno e così via a seconda di come si configura e utilizza il quadro di registrazione. La pagina gialla di IIS/ASP.NET potrebbe non essere completa ma dovrebbe comunque mostrare la traccia dello stack.

se si vuole buttare il proprio un'eccezione da un blocco catch si avvolge l'eccezione effettivo proveniente dalla cattura in questo modo:

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

Edit: provato quello che lei ha suggerito e ottenuto il seguente login un file di testo 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

prova questo e capirai cosa sto dicendo: prova { lanciare SecurityException ("eccezione originale"); } catch (SecurityException ex) { lanciare nuove SecurityException ("eccezione più esplicita", ex); } –

+0

sì, ho capito, ma provo a scaricare tutto con un framework di registrazione, cosa ottieni nel file di registro? –

+1

In questo caso, il messaggio è principalmente per gli sviluppatori.Voglio che venga sollevato il messaggio di errore amichevole in modo che gli sviluppatori lo vedano in fase di debug, non per la registrazione e quindi ottengono messaggi di facile comprensione piuttosto che criptici. –

5

Questo comportamento ha origine nel "core" ASP.NET, non in ASP.NET MVC. Sfortunatamente, le classi di formattazione degli errori sono interne e i tipi di consumo non forniscono alcun punto di estensione che consentirebbe di modificare il comportamento senza sostituire il meccanismo di segnalazione degli errori. La soluzione alternativa è di sostituire la pagina "schermata di morte gialla" predefinita con una pagina di errore personalizzata/vista in cui si espongono le informazioni che si preferiscono.

Questo è esattamente ciò che si dovrebbe fare di solito per la produzione. Nel tuo caso, significa semplicemente che avresti una versione alternativa per il debug invece di utilizzare l'impostazione predefinita fornita da ASP.NET.

Problemi correlati