Learning WCF

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, and VersionMismatchFaultDetail.

• Always provide an appropriate reason and fault code when throwing FaultException or FaultException<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 ...