duplex communication and passing exceptions

I have create开发者_StackOverflow中文版d a WCF web service that connects to an XMPP service with Jabber.net. The idea is that the service will act as a proxy for Silverlight clients to use for messaging.

IMessagingClient.cs:

[OperationContract(IsOneWay = true, AsyncPattern = true)]
IAsyncResult BeginError(Exception ex, AsyncCallback callback, object state);
void EndError(IAsyncResult result);

In my server code I have connected an error handler to the JabberClient

private void xmppClient_OnError(object sender, Exception ex)
{
    lock (xmppClient)
    {
        Debug.WriteLine("xmppClient_OnError: {0}", ex);
        // Let the client know there has been a problem
        client.BeginError(ex, OnSendErrorCompleted, client);
    }
}

However when a SocketException occurs it fails to pass the exception.

System.ServiceModel.CommunicationException: There was an error while trying to serialize parameter http://tempuri.org/:ex. The InnerException message was 'Type 'bedrock.net.AsyncSocketConnectionException' with data contract name 'AsyncSocketConnectionException:http://schemas.datacontract.org/2004/07/bedrock.net' is not expected. Consider using a DataContractResolver or add any types not known statically to the list of known types - for example, by using the KnownTypeAttribute attribute or by adding them to the list of known types passed to DataContractSerializer.'. Please see InnerException for more details.

Now I understand that it can't be serialized because it doesn't understand how to send the exception and I am not convinced I should be sending this specific exception anyway as it then makes the client need to know about the inner workings of the messaging on the server.

But what is the best way to do this? Should I even be sending this sort of Exception from server to client? I saw some examples using `FaultContract' but not how (or it it should) apply to pushing.

You should use fault contracts as they are an explicit contractual declaration of faults that can be communicated to a client consumer of the service i.e the client will know what types of faults to expect.

You should not send this type of exeption detail to the client,as it could be a security risk or irrelevent to the client, you should aim to abstract the consumer from the details of the exception. You could log the exception and then raise a fault maybe something like new FaultException, mapping the actual exception to an FaultReason or FaultCode that you can use later to correlate the exception that occured on the service.