While the default error-masking policy of WCF is a best practice, there are times when
you are refrained 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 expectations 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 must throw an
instance of the
FaultException<T> class, defined in
Example 6-1. The FaultException<T> ...