Today I was busily working on an ASP.Net app when I was confronted with the dreaded "Sys.WebForms.PageRequestManagerServerErrorException":
As anybody who has spent a fair amount of time working with ASP.Net can attest, this is one of the last things you want to see pop up because it is next to useless for figuring out what is actually wrong. Assuming you follow good practices in terms of error handling, odds are pretty good that when you see this the bugs isn't even in your code. Usually, it will end up being a bug in some flaky declarative control you're using.
Personally, I think that the Microsoft Moron who decided that bubbling server errors up to javascript before breaking should be tarred, feathered, and made to watch the Complete Works of Pee-wee Herman. Twice!
Anyway, enough ranting. So how do you get at some useful info? Basically, you need to trap the error somewhere that will allow you to interact with it.
One place is the Global.asax file's Application_Error event handler. This will catch anything not handled elsewhere:
protected void Application_Error(Object sender, EventArgs e)
{
try
{
Exception ex = Server.GetLastError();
if (ex != null)
{
//log it or do something else useful...
}
Context.ClearError();
Server.ClearError();
}
catch { }
}
Another is the page in question's Page_Error handler:
protected void Page_Error(object sender, EventArgs e)
{
Exception ex = Server.GetLastError();
if (ex != null)
{
//log it or do something else useful...
}
Context.ClearError();
Server.ClearError();
}
In either case, put a breakpoint in the location where the logging goes. You'll now have full access to the exception, complete with call stacks, etc.
BTW, in case you were wondering: no, the actual problem above was not because the "Status" field was missing from the "Pages" table -- that would have been way too easy.
Subscribe