The point of having FaultContracts is to make it possible to first of all pass back SOAP faults from the service which will not break the communication channel between the server and the client (handling error conditions like .NET exceptions gracefully and interoperably), and secondly, using FaultContracts, your server than throw typed faults (FaultException<T>
) and your client can catch those.
If you want or need to be really interoperable, you need to:
- define all your FaultContract types as classes decorated with the [DataContract] attribute
- catch all .NET exceptions on the server (using e.g. IErrorHandler interface) and turn them into interoperable SOAP faults
If you control both ends of the wire and both ends are .NET, then you can simplify this by one step: on the server, handle all .NET exceptions and turn them into e.g. FaultException<ArgumentOutOfRangeException>
, that is, create a "fault of (whatever .NET exception)" and then on the client, catch those typed FaultException and handle them:
[FaultContract(typeof(ArgumentOutOfRangeException)]
[OperationContract]
public void CallService(.......)
and then in your implementation, use this:
try
{
clientProxy.CallService();
}
catch(FaultException<ArgumentOutOfRangeException> ex)
{
// handle the most specific exception first
}
catch(FaultException ex)
{
// handle all other, unspecific server faults
}
catch(CommunicationException ex)
{
// handle all other, client-proxy related WCF errors
}
catch(Exception ex)
{
// handle anything else....
}