Page_Error versus Application_Error Error Handling??

M

Matt

Can anyone give me a good reason to use BOTH application scope Page_Error
and the page scope Page_Error when trapping errors in a web application? Is
there any real benefit to using the Page_Error if you are already capturing
errors in Application_Error? Also, if you have any links to discussions
about when to use which function it would be helpful.
 
M

Marina

In Page_Error you can redirect the user someplace, or just change the output
of the page to some user friendly error message.

In Application_Error, all you can do is log the error somehow. You can't do
anything with the request.

I would use Application_Error for those cases where the page isn't handling
the error for some reason, as a last resort to log the error. If a page can
handle its own errors and gracefully deal with them, it should do so in
Page_Error.
 
C

Clint Hill

Good question. And subsequently not a really good answer.

"It depends".

I know that isn't what you wanted to hear, but let me explain. Page and
Application two different scopes (obviously). And so with that in mind,
your Exceptions would occur in one and/or the other scope.

How far up the stack do you want to catch errors?

Clint Hill
H3O Software
http://www.h3osoftware.com
 
G

Guest

There are times where you can compensate for an error at the page level
rather than send it up to a generic application level handler. It is all a
matter of scope. As much as possible, try to handle things at the smallest
scope you can.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***************************
Think Outside the Box!
***************************
 
C

Clint Hill

Actually you can redirect and do whatever you like with the Request
inside of Application_Error. You can use the Response.Redirect or grab
the HttpContext.Current and do whatever.

Clint Hill
H3O Software
http://www.h3osoftware.com
 
M

Matt

Well, all we want to do is catch any error that the app experiences, write
the error stack, the page name, and other information to the database, and
send an email to the developers. We already handle some small stuff with
try/catches and appropriate messages to the user within applications. This
is for data connection problems, 404's, etc. that wouldn't be the user's
fault.

I was under the impression that you could do it piecemeal in each page, OR
consolidate it in the Application_Error function. Any error that doesn't
get caught in the Page_Error, or any error that IS caught but isn't cleared,
gets caught by the Application_Error in the global.

Since we're just capturing each error for our notifications purposes and not
having different actions for each page, I thought that the best thing to do
would be to do this once in the Application_Error. The error gets put in
the database, the email gets sent, and the user is shown an error page as
assigned in the CustomErrors node in the web.config.

Other developers here feel that we should have both the Application_Error
AND the Page_Error in use; but they are not talking about having specific
Page_Errors for individual pages. They are talking about putting a
catch-all Page_Error in our custom Page base class, from which all our pages
inherit. The justification that was offered for this is that they say there
are errors that aren't necessarily 'application errors' but are actually
'page errors', and that these errors will not be trapped by the
Application_Error function... but they will be caught by the Page_Error
function. I tend to believe that isn't true; any .NET error will be caught
by the Application_Error (since the application is actually the entire
website); and that in this situation, using both the Application_Error and
the Page_Error is redundant.

Am I wrong? If so, could someone give me an example of some C# code that
could cause an error that would be trapped with the Page_Error function but
not by the Application_Error function?
 
M

Matt

Is there any reason, in doing generic error logging, to use the Page_Error
(unless you are doing something specific to that page)?
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,755
Messages
2,569,536
Members
45,007
Latest member
obedient dusk

Latest Threads

Top