What to do with a caught exception

Question

When the WCF service is turned off, I'm gonna catch this exception like this.

   public List<ProjektyEntity> GetProjekty()
   {
      try
      {
         return this.channel.GetProjekty();
       }
       catch (EndpointNotFoundException exception)
       {
          //what to do at this point ?
       }
    }

But i don't know what to do in the catch block.I can return only an object of type List<ProjektyEntity> I'd like to write a message to the user,something like "The service is turned off" My presentation layer is ASP.NET MVC. Is there any strategy for this kind of situations?

Answer 1

There's a simple rule: If you don't know how to handle an exception, don't catch it.

Catching it and retuning null or an empty list would be about the worst thing you can do because it will be hard to debug where the error is coming from, or even that an error occured at all. If you do this you will have developers pulling their hair out.

Catching an exception and rethrowing it as throw e; is also bad because you lose the original stack. Rethrowing using throw; is OK sometimes if you have special clean up you need to do only if there is an error. Usually this is not the case. If you have cleanup that should be done whether or not there was an error, it belongs in the finally clause.

So in general unless there is something sensible you can do to recover from the error, just let the exception propogate to the caller. This is how exceptions are designed to work.

There are a few times when you might want to catch an exception to add more information (e.g. for logging), in which case you should ensure that you use an InnerException to avoid losing the original information:

try
{
    foo(bar);
}
catch (Exception e)
{
    throw new FooException("Foo failed for " + bar.ToString(), e);
}

but in general it's best not to do this unless you have a very good reason. Doing this prevents your users from catching a specific type of exception - they will catch your exception and then they need to switch on the type of the InnerException. Not fun. Just let the caller see the original exception.