In the Global.asax, there is an Application_Error event which gets triggered whenever an unhandled exception bubbles up to the top without being caught by any other functions (so, on a website, that'd be a case where you get the yellow error page). If the code is trapping exceptions at a lower level and displaying text (which good code should be doing), you can't really use that event to capture an error.
For our developers' code, we log the exceptions in a database and fire off e-mails. In their code, they do this in try-catch blocks, but there's a catch-all Application_Error that looks a little bit like:
protected void Application_Error(object sender, EventArgs e)
{
ExceptionChit chit = null;
Boolean UrlNotFoundException = false;
Exception ex = HttpContext.Current.Server.GetLastError().GetBaseException();
try
{
if (ex is HttpException)
{
HttpException hex = (HttpException)ex;
if (hex.GetHttpCode() == 404) UrlNotFoundException = true;
}
if (!UrlNotFoundException)
{
//This logs the exception and sends out the relevant e-mail.
chit = ExceptionChit.LogException(ex, Request, "Application", "Username");
}
Server.ClearError();
}
finally
{
if (UrlNotFoundException)
{
Response.Redirect("~/Default.aspx");
}
else
{
//Do some other stuff that I've taken out from here.
}
}
}
The exception chit code saves a record in a table, and then you could have a SQL Agent job run every few minutes or so to send out e-mails. ex (the exception) contains properties like Message and StackTrace, so you could put them directly into the table. The stack trace can get pretty long, though, so you may want to think about maintenance with that table if you have a lot of exceptions.
I believe you would need to be able to re-compile the code before Global.asax changes take effect. I haven't messed with the Report Manager code, so I don't even know if you can compile it yourself.
↧
