Programming WCF Services, 3rd Edition

Fault Propagation

While the default error-masking policy of WCF is a best practice, there are times when you should refrain from relying on it. This is typically the case when there is an existing application (or communication pattern) in place, and the service is required to throw particular exceptions as it processes inputs, reaches certain states, or encounters errors. The client is required to respond to these exceptions in a prescribed way. Obviously, controlling the flow of the application using exceptions is hardly a good idea, as it leads to nonstructured programming and couples the client to the service. And yet, the underlying requirements remain: the service is required to report specific errors to the client, and the default masking of the errors by WCF precludes that. Another fundamental problem pertaining to propagating the error to the client is that exceptions are technology-specific, and as such should not be shared across the service boundary. For seamless interoperability, you need a way to map technology-specific exceptions to some neutral error information. This representation is called a SOAP fault. SOAP faults are based on an industry standard that is independent of any technology-specific exceptions, such as CLR, Java, or C++ exceptions. To return a SOAP fault (or just a fault, for short), the service cannot throw a raw CLR exception. Instead, the service could throw an instance of the FaultException<T> class, defined in Example 6-1.

Example 6-1. The FaultException<T> ...