Question

I know it is not good to just put a try catch with Exception on it since that could lead to burying problems and other things.

I however still don’t know if I should do it in my case.

My site is heavy ajax so I send json responses back. So right now I have identified some possible exceptions that could be raised like a null reference, sql db and etc.

So in the catch statement of these ones I would have a nice message to the user something like

a database error has occurred your
stuff has not been saved

However I am thinking what happens if their is some other exception that I don’t see right now. If that would happen I think the form would just hang and the user would not know what is going on.

So would it be better in this case to

• catch exceptions that I identified -such as sql, outof range
  • log with elmah
  • show nice customized msg for each exception
• catch Exceptions after
  • log with elmah
  • show some generic msg
  • come back and add that exception list.

So

catch(IndexOutOfRangeException ex)
{
    // log here
    // customized msg
}
catch(Exception ex)
{
    // log here
    // generic msg
    // come back and add another exception later on what actually failed.
}

instead of

catch(IndexOutOfRangeException ex)
{
    // log here
    // customized msg
}

Answer 1

Hiding exceptions could not be a good idea because it would hide an error of the code, and would not allow you to understand what is wrong. Not all the errors should be shown to the users who use that knowledge to attach your site.

Rather than showing an error to the user, I would log it in a database, or in a file; you can show to the user an error message, but the error message could a code that only you know what it means. It’s what is done from a cache server, that returns to the user a error code called guru meditation.

My answer is then: catch all the exceptions, even the ones you didn’t think could be raised. This will allow you to control the error message users would see.