ASP.NET MVC2 - number and location of try/catch(throw?) blocks

Question

I'm in the process of thrashing through the whole exception-handling jungle, and I'm now trying to determine just how many try/catch blocks I need, and where to put them.

From my controller I have

CreateInvitation(fromUser, toUser);

which calls down to my BLL method

public static Invitation CreateInvitaton(User fromUser, User toUser)
{
    try
    {// see if toUser exists, then create the invitation}
    catch
    {// throw something, maybe?}
}

Do I actually need to re-throw it in that method? Won't it go back up the stack even if I don't re-throw it?

Do I need to wrap the controller's call in a try/catch block too, or is that redundant?

Maybe I don't need the try/catch block in the BLL method at all, and only need a try/catch block in my controller?

I'm looking at quite a few possible combinations here, and have no idea what the proper one is.

Thanks.

Answer 1

The exception handler, as written in your example, is doing absolutely nothing. (well, it's wasting a little bit of time, but it's doing nothing of use)

Had it been:

try 
{...} 
catch 
{ 
  // do something here.
   throw;
} 

Then the try/catch & throw would be needed.

Answer 2

Catch exceptions locally if and only if they indicate exceptional behaviour and can be fixed (or commented) locally.

Hard enough to find an example - here's one: I have some objects which need pessimistic lock. The lock is needed because writing to the object from the web application while another (background) app is reading it could lead to disaster. It is truly an exception, because it will happen very rarely. Moreover, I can do nothing about it beforehand (because the lock might have been acquired just before the next line is executed). However, I can retry in a few msecs, because I know chances are good the object is released again. Still, all this does not happen in the controller, but in a service class.

Don't use exceptions for expected conditions (invalid input, for example).

Also, I agree most exceptions in web applications cannot be handled except for logging a message (which should not be done in the controllers) and sending an error page. Lastly, when catching exceptions, make sure to do it right (catch a specific exception type, retrow with throw; not throw ex;)