More on customErrors and session state
In an earlier post I made mention of my observations that the Session variables are cleared when ASP.NET uses its <customErrors defaultRedirect=”YourErrorPage.aspx” mode=“On“ /> section, because noone managed to catch an exception.
Since then I came across this article by Eri Robillard, that was posted on the 27th of January. I must have missed it, and somehow it didn't show up during my Google session on the matter.
Although the article doesn't explain why the session variables are cleared, it does mention the ways to pass control after an exception that occured in combination with the manner of passing (parts of) the exception along.
From the article:
| Storage Basket | Control-passing methods that work |
|---|
| Application | Response.Redirect(), Server.Transfer(), or customErrors:defaultRedirect |
| Cookies | Response.Redirect(), Server.Transfer(), or customErrors:defaultRedirect |
| Context, Session | Server.Transfer() |
| QueryString | Response.Redirect() or Server.Transfer() |
So, in this respect, you could use the <customErrors> section if you change the code ínside Global.asax to:
HttpUnhandledException ex =
(HttpUnhandlesException)Server.GetLastError();
Application.Lock();
Application[Session.SessionID + “Exception“] = ex.InnerException;
Application.Unlock();
// Do not call Server.ClearError, so the exception will be caught
// by ASP.NET, which will evaluate <customErrors>
Obviously, the YourErrorPage.aspx would then retrieve the exception from the Application variable like so:
Exception ex = Application[Session.SessionID + “Exception“];
I haven't tried this out yet, nor have I checked if the behavior is different in Whidbey. Let me know if you tried or check it already.