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?