views:

841

answers:

2

What's the deal with CommunicationExceptions in a system using WCF? I have a client communicating with a server through WCF using SOAP - all async communication. Occasionally I get a CommunicationException thrown in my face - without seeing any reproducible pattern on why and when this happens.

However; I am able to continue running the program as this is only a first chance (?) exception. Therefore I assume I don't have to worry about this, and that it is handled behind the scene? But I'm still concerned, and it would be nice if someone could enlighten me on this. Should I try-catch for CommunicationException every place I call a function through WCF?

A: 

You could try something like this:

try
{
    ...
    client.Close();
}
catch (CommunicationException e)
{
    ...
    client.Abort();
}
catch (TimeoutException e)
{
    ...
    client.Abort();
}
catch (Exception e)
{
    ...
    client.Abort();
    throw;
}
Shiraz Bhaiji
Added this on the client side, but the exception never reached the client as it is a first chance exception. But should one in general do try-catching for such exceptions when using WCF, or can I assume no communication-type exceptions being thrown?
stiank81
You should also catch the exception on the server side and throw it as a fault exception if you need to send an exception to the client. Which fault exceptions are thrown must be specified in the WCF contract.
Shiraz Bhaiji
Really? I need to do this on everything in case there is a communication exception of some kind? Was kinda hoping WCF would handle this for me. I tried catching exception on both sides, but this changes nothing. Still just seeing the first chance exception - which is in the EndMyServiceFunc() in the autogenerated reference.cs. But you're saying there is a chance this might blow up at some time if I don't handle such exceptions?
stiank81
+1  A: 

The CommunicationException is the base type for all WCF related problems and can appear at the client in a multitude of cases:

  • when your client e.g. requests a URL that's not available
  • when your server is too busy and can't handle any more requests and rejects a request
  • when something goes wrong on the network between client and server (connection dropped etc.)

If you have these pop up frequently, you'll need to check more closely if they're really CommunicationException or some derived type (FaultException and many more).

A FaultException would be an indication that something on the server went wrong - it will be thrown if the server got the request, but couldn't handle it properly and returned an exception or a SOAP fault.

Did you note what the message of the exception was, and whether there was any InnerException?

Marc

marc_s
Thx! If I understood you correctly this means that I should try-catch for CommunicationException on every MyFunctionAsync() call on the client side..? But I assume there is no need to do this on the server side? In my case it doesn't happen often. Takes a while of sending frequent requests until I'm able to reproduce. The exception says "NotFound", and the InnerException seems to a WebException. Only get this as a first chance exception in debug mode..
stiank81
Yes, on the client, I would definitely put my service calls in try..catch. On the server side, you'll need to check into the IErrorHandler interface and implement that on your service class to catch any exceptions that happen on the server and convert them to SOAP faults to be totally "clean" ;-)
marc_s
Thx! Will be on the alert for possible exceptions on the server side and convert them if there are any.
stiank81
I never saw the exception as more than a first chance exception before, but now I'm using the MyFunctionCompleted() callback event, and doing so it blows up inside ..Completed(). Comes there as a TargetInvocationException with CommunicationException being InnerException. This is all expected to happen once in a while, right? Just catch the exception and I don't need to worry about me having added some silliness to the communication?
stiank81
IF there's any exception during an async call, the exception will happen on the EndMyAsyncCall method, that's correct. Not sure why it would throw a TargetInvocationException - hmm... might require some additional investigation
marc_s