The point of presence of FaultContracts allows you to first send back SOAP errors from a service that will not break the communication channel between the server and the client (error handling, such as .NET exceptions, is elegant and interoperable) and secondly, using FaultContracts, your server than throw typed errors ( FaultException<T> ), and your client will be able to catch them.
If you want or need to be truly compatible, you need to:
- defines all FaultContract types as classes decorated with the [DataContract] attribute
- catch all .NET exceptions on the server (using, for example, the IErrorHandler interface) and turn them into compatible SOAP errors
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, for example. FaultException<ArgumentOutOfRangeException> , i.e. create an "error (regardless of the .NET exception)", and then catch the introduced FaultException on the client 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.... }