Summary
In this chapter, you learned how to deal with exceptions for your WCF clients and
services. You learned that the default behavior is to suppress uncaught exceptions to
protect the system from sharing proprietary information; you learned how to enable debugging
behaviors to share exceptions during development; you learned how throwing any form of
FaultException
will not fault the service channel and
will pass more useful information to clients; and you learned how to create reusable code to
control how faults are propagated to clients. Some recommendations you can take away from
this chapter are as follows:
Do not return exceptions as faults except in development. Avoid enabling this on the service type since this will prevent administrators from disabling the feature in configuration.
Declare just a few meaningful data contracts for the fault detail element, and map known exceptions to those types when you generate faults. Avoid returning CLR exception types in the details element since this is .NET specific. For interoperability, data contracts are preferred. Examples of possible data contracts to create are
ReceiverFaultDetail
,SenderFaultDetail
, andVersionMismatchFaultDetail
.Always provide an appropriate reason and fault code when throwing
FaultException
orFaultException<T>
.Consider the differences between SOAP 1.1 and 1.2 when generating fault codes.
MessageFault
can serialize to either format according to the bindingâs envelope version, but there are subtle differences ...
Get Learning WCF 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.