Exception handling and custom error pages

[C.]

Hi,

I have an app that uses a Linq-to-Sql provider. If the database were
to go offline, I would like the user to be re-directed to a friendly
error page that reads from Session["ErrorMessage"], and I would like
to log the SqlException's details in the health monitoring system I
have set up so the admin is notified with an email.

My first thought was to handle the Application's Error event in the
Global.asax like so:

void Application_Error(object sender, EventArgs e)
{
Exception exc = Context.Server.GetLastError();

try
{
throw exc;
}
catch (System.Data.SqlClient.SqlException)
{
System.Web.Management.WebBaseEvent.Raise(new
ND.CustomEvents.DataStoreUnavailableError("Could not connect to the
data store", null, exc));

HttpContext.Current.Session["ErrorMessage"] = @"We are currently
experiencing difficulties with our database. Our administrator has
been notified, please check back soon.";
}

Context.Server.ClearError();
}

However, the exception that gets passed by GetLastError() is of type
"System.Web.HttpUnhandledException", which contains an inner exception
of "TargetInvocationException", which finally contains the
SqlException I want to handle.

Is there a better way of doing this? I could wrap each and every
method in my data access objects in a try/catch, but I'd like to
centralize my exception handling if at all possible.

Regards,

Chris

 

[C.]

Oh and if it matters, the reason I'm getting the
TargetInvocationException exception is because the linq-to-sql
provider sits below an abstract provider class. So what I'm trying to
get at is if there is a way to centralize the exception handling in
this case without having to interrogate all the innerexceptions of the
exception I get passed.

Regards,

Chris

 

[Andy O'Neill]

Hi,

I have an app that uses a Linq-to-Sql provider. If the database were
to go offline, I would like the user to be re-directed to a friendly
error page that reads from Session["ErrorMessage"], and I would like
to log the SqlException's details in the health monitoring system I
have set up so the admin is notified with an email.

How often are you planning on your production database being offline?

 

[Mike Lovell]

Is there a better way of doing this? I could wrap each and every

method in my data access objects in a try/catch, but I'd like to
centralize my exception handling if at all possible.

Hook up the unhandled exception event:

http://www.gotinker.com/2010/03/16/handling-unhandled-exceptions/

 

[Andy O'Neill]

Hook up the unhandled exception event:

http://www.gotinker.com/2010/03/16/handling-unhandled-exceptions/

What's the advantage to that approach over handling in global.asax.?
I don't see any.

 

[C.]

How often are you planning on your production database being offline?

I don't expect it to go offline often, but I was hoping to template
handling exceptions based off this as an example.

Regards,

Chrus

 

[Andy O'Neill]

I don't expect it to go offline often, but I was hoping to template
handling exceptions based off this as an example.

Regards,

Chrus

I would hope it'll almost never go offline.
In which case, is it really worthwhile trying to come up with a way to tell
the user "the database is offline" rather than "there's some sort of error"
when they do anything. Most people work out pretty quick that if they try
and do ANYTHING and they get errors then there's a big bad problem and they
better report it to support.
Personally, I use global asax and one error reporting page in order to hide
from the user all that stack.
It confuses them seeing all that gobbledigook and they also tend to think
you will be able to work out exactly what they did "wrong" when they got the
error if they just send it you. Often the stack trace is flip all use and
you really want them to say first I did this and then I did that..

You could dig down through the layers of exception details and find the base
exception.
Or stop them being wrapped as they go up each layer.
You need to mess with the way errors bubble though and in turn that makes
bug tracking in dev a pain.

The errors though.
They're a collection and you need code which can cope with a bunch of them
and work out what each means.
That can be quite a lot of code.

What are you using for your dal/bal?
If you're using linq to sql you can extend all your classes to have a
central way of handling sqlexceptions.
You might have to use EF4 to do that with Entity Framework.