Is it best to handle SQL Exceptions or rather use a customError page and the Application_Error method in Global.asax?

Question

I am using ASP.Net 2.0. I found myself in an awkward situtation because I could not find the cause of an error. Up until now I have been using this idiom when it comes to accessing data.

try
{
  access data
}
catch (SqlException exception)
{
  Response.redirect("error.aspx");
}
finally
{
  Dispose of connections, commands etc
}

Now I can never see what the actual error was because it is always handled. Sometimes I can run SQL Profiler and catch the last statement and run that in SQL Query Analyzer and see if there is a problem. That is obviously terrible.

So I thought that the global.asax Application_Error method would save me and I would email myself the exception. But this method seems to only be called for unhandled exceptions. So my question is, is rather better to not handle the exception at all, the system sends the email and use a customError page. Or is it better to ram the exception into the session, redirect to the error.aspx and try and do something with the error then. Is there a way to call Application_Error again? Because if I throw the exception again at the error.aspx then I get the yellow screen of death?

Answer 1

In my opinion, use a library (log4net for example) to log your exceptions and throw the exception again, let the asp.net redirect the error page to a custom page with web.config customErrors section.

Log4Net or Enterprise Library's Exception Handling Application Block both have email sending features.

Also take a look at ELMAH, very smart and pluggable exception handling module.

Answer 2

Logging would be invaluable here. In your catch blocks, log the error out to a log file. its a good idea to get in the habit of doing this at it can be a real life saver to see whats going on. Have a look at nlog which is a logging library. There are various tools out there too that allow you to analyse logs produced by nlog

Answer 3

You can simply log the exception somewhere before redirecting to the Error page.

Something like :

try
{
  //access data
}
catch (SqlException exception)
{
  LogException(exception); 
  Response.redirect("error.aspx");
}
finally
{
  //Dispose of connections, commands etc
}

Thus you can have it both ways, Customer will be directed to error page and still your exception is logged somewhere for you to review and get to the bottom of it.

By the way, there are many free logging libraries that you can use notably log4net and Enterprise library

Answer 4

Since you are using ASP.NET 2.0, your best bet is to do nothing.

ASP.NET added a feature called ASP.NET Health Monitoring. By default, this will log detailed exception information to the Application event log. It can be configured to send different kinds of problem to different destinations.

So, simply do nothing, and everything will be fine.