C
Carl Johansen
I've been reading the O'Reilly "ASP.NET Cookbook" 1st edition (Kittel and
LeBlond), and it makes a recommendation about exception handling that seems
a bit strange. They say that, if you want to let some exceptions propagate
up to Application_Error, you should include the following Page_Error on
every page:
Private Sub Page_Error(ByVal sender As Object, ByVal e As System.EventArgs)
Handles MyBase.Error
Throw Server.GetLastError()
End Sub
Their reasoning is that this prevents ASP.NET from wrapping your exception
in an HttpUnhandledException. They say that this wrapping is not 100%
consistent, so you need the Page_Error handler to make it easy for your
Application_Error handler to find the "real" exception.
I tried this out (actually I added the Page_Error handler to a class derived
from System.Web.UI.Page so I don't have to add it to every page) and, sure
enough, it prevents the HttpUnhandledException. But I seem to pay a high
price for it. When, after Application_Error is done, I get the ASP yellow
error screen on my workstation, it no longer pinpoints the line and stack
that caused the exception. Instead, it always shows the "Throw
Server.GetLastError()" line and the stack for the call to Page_Error! Not
very helpful. Sure, I could write the real error to the event log and read
it there - but what a drag.
Has anyone else thought about using/not using this technique?
Thanks in advance,
Carl Johansen
www.carljohansen.co.uk
LeBlond), and it makes a recommendation about exception handling that seems
a bit strange. They say that, if you want to let some exceptions propagate
up to Application_Error, you should include the following Page_Error on
every page:
Private Sub Page_Error(ByVal sender As Object, ByVal e As System.EventArgs)
Handles MyBase.Error
Throw Server.GetLastError()
End Sub
Their reasoning is that this prevents ASP.NET from wrapping your exception
in an HttpUnhandledException. They say that this wrapping is not 100%
consistent, so you need the Page_Error handler to make it easy for your
Application_Error handler to find the "real" exception.
I tried this out (actually I added the Page_Error handler to a class derived
from System.Web.UI.Page so I don't have to add it to every page) and, sure
enough, it prevents the HttpUnhandledException. But I seem to pay a high
price for it. When, after Application_Error is done, I get the ASP yellow
error screen on my workstation, it no longer pinpoints the line and stack
that caused the exception. Instead, it always shows the "Throw
Server.GetLastError()" line and the stack for the call to Page_Error! Not
very helpful. Sure, I could write the real error to the event log and read
it there - but what a drag.
Has anyone else thought about using/not using this technique?
Thanks in advance,
Carl Johansen
www.carljohansen.co.uk