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> ...
Get Programming WCF Services, 3rd Edition now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.