General way to handle exceptions

Question

I'm trying to design the exception handling mechanism in my web app, and got into some difficulties in the design.

As much as I know - there are three ways to catch exceptions in ASP.NET app -

1. In the code itself (try, catch, finally)
2. In the Page_Error event of the page
3. In the Application_Error event of the global.asax page

Since I have many events and functions in my .aspx pages, I wanted one single place that will catch and collect exceptions. In other words- I really don't feel like spreaindg try-catch statments all over the code, so I thought using the Page_Error event (which I read might be good practice at some cases).

However, a problem arises because all I want the exception handler to do is to show a nice alert on the page itself informing about general problem that took place, but as you probably know - when you get to Page_Error the page is already dead and failed to render.

So, what other generic way is there to catch exceptions, in a manner that when I will write functions in the future I won't need to think about exceptions or try-catch, but instead know that there is a mechanism somewhere out there that will catch everything and handle it?

Answer 1

Use Elmah - http://code.google.com/p/elmah/

This will catch and log any unhandled errors, without your writing a line of code :)

Answer 2

Since an exception occurred it means the page could not render (for whatever reason). This will cause an exception to propogate up the call stack until it is handled somewhere. The last place you can handle an exception in ASP.NET is within global.asax and since there was a problem you can create whatever output you want to be written to the client:

protected void Application_Error(Object sender, EventArgs e)
{
  Response.Write("Really sorry this happened")
}

This method will ensure all (unhandled) exceptions will be caught and treated in this way, so you'll also likely want to implement some kind of logging system here too.

Of course you can also specify a custom error page in the web.config.

Answer 3

I believe that not try/catching exceptions at all could restrict you from some benefits/techniques like Repeating a function in C# until it no longer throws an exception. Anyway you can allow show custom error page on web.config if it fits.

I would personally use Application_Error in order to log that exceptions, but in this sense, better would be giving @MoXplod advice a try.

Btw, I might not be totally correct but writing the stacktrace to a page when an error occurs could consist of a security issue.

Answer 4

I use Application_Error to log the error and then do a Server.Transfer to a custom error page. By doing it this way I can grab the exception on that page and decide how to display it. I worry though that if you are wanting to show the exception in an alert that you may be using exceptions for the wrong purpose. You aren't throwing exceptions for validation errors or something else that can be anticipated, are you?

Answer 5

The only real way to properly handle exceptions is to do so as close as possible to the offending code. This way you have much better control over how it should be best handled. In other words, having those try-catch statements "all over the code".

Take, for example this bit of code:

Int32 value = 0; // let's say this was passed in.
double newValue = 5 / value;

Is it better to alert the user that a problem occurred or is it better to have a fall back plan, for example, just assigning 0 to newValue? Your answer may change depending on the situation; however, if you are dealing with this in a generic way you artificially limit yourself.

Answer 6

In my case I ended up using Post Sharp, an AOP framework. I used it to enter some policy when exception occured.

Another option is Enterprise Library's policy injection, which allows code insertion in particular cases, such as - methods or classes surrounded by an attribute, and an Exception Handling Module attached to it.

This way or another, the solution for catching exception in an "abstract" (so to speak) level without filling the code with try-catch will probaby contain this amount of AOP.

goodluck