Page_Error, Application_Error and HttpUnhandledException

[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

[Buddy Ackerman]

I'm not 100% sure but I use Server.GetLastError().GetBaseException() and I
think that gets by and HttpUnhandledException issues. I'm not sure exactly
what the real probleem is anyway but I've not had any issues using the above
(in teh Application_Error procedure) to get what I need.

--Buddy
"Carl Johansen" <carl@_NOSPAM_carljohansen.co.uk> wrote in message
news:Op**************@TK2MSFTNGP14.phx.gbl...

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

[Brock Allen]

The point of HttpUnhandledException is to let you know if the error was during
processing of your pages or if the error was from something else, such as
a configuration error, a page compiler error, or a 404 error. Many times
in Application_Error you check:

void Application_Error(...)
{
if (Context.Error is HttpUnhandledException)
{
// ok, this is a runtime code problem
}
else
{
// ok, this is something else
}
}

-Brock
DevelopMentor
http://staff.develop.com/ballen

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