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.

Answer 2

It seems to me that you should not catch this exception at that layer; you should let the exception propagate up to the controller layer and let the controller layer displays the message.

Answer 3

I can see a few options here. Determining which is appropriate is probably dependent on the application.

• Display an error and return null. Clean and simple, but inflexible. May not be what you want in every case where this function is used.
• Don't catch it, let the caller catch this exception. It may be easier to determine the appropriate response from the calling function (ie. display a message / retry in a few seconds / etc)
• Catch it and throw a new ServiceNotAvailableException Slightly more complex than option two, but will make your code clearer.
• Just return null. Probably the least desirable approach unless this service being down is common and no big deal.

Answer 4

Create an exception object with enough debugging details and throw it to calling method

Answer 5

The exception is not supposed to be caught and handled in this context. It needs to be handled at much higher level having access to any console in general.

The best you can do here is just log the exception with necessary details and rethrow properly.

Answer 6

There are several approaches:

1) Don't catch the exception, and let the caller (user interface layer) handle it

2) Catch the exception so you can do anything you need to do, and then re-throw it

catch (EndpointNotFoundException exception) 
{ 
   CleanUpMyOwnState();
   throw;                  // Pass the exception on the to the caller to handle
} 

3) Convert the exception into another type (to make it easier to handle in the caller):

catch (EndpointNotFoundException exception) 
{ 
   CleanUpMyOwnState();
   throw new InvalidOperationException("Endpoint was not found", exception);
} 

4) catch it, and then return an error code (e.g null), so the caller doesn't need to use exception handling to deal with it (but there's no real advantage to doing this)

5) Catch the exception and report the error to the user yourself. This is probably a bad idea - you should keep all error reporting in your UI layer.

Answer 7

 public List<ProjektyEntity> GetProjekty()
   {
      try
      {
         return this.channel.GetProjekty();
       }
       catch (EndpointNotFoundException exception)
       {
          'Write here Some Clean Up Codes
          ' Log it somewhere on your server so that you can fix the error

       }
    }