Programming WCF Services, 4th Edition

Chapter 6. Faults

Any service operation can, at any moment, encounter an unexpected error. The question is how (if at all) that error should be reported back to the client. Concepts such as exceptions and exception handling are technology-specific and should not transcend the service boundary. In addition, attempts by clients to handle errors invariably lead to increased coupling. Typically, error handling is a local implementation detail that should not affect the client, partly because the client may not care about the details of the errors (other than the fact that something went wrong), but mostly because in a well-designed application, the service is encapsulated so that the client does not have to do anything meaningful about the error anyway. A well-designed service should be as autonomous as possible, and should not depend on its clients to handle and recover errors. Anything beyond a blank error notification should in fact be part of the contractual interaction between the client and the service. This chapter describes just how the service and the client should handle these declared faults, and how you can extend and improve on the basic mechanism.

Error Isolation and Decoupling

In traditional .NET programming, any unhandled exception (except ThreadAbortException) immediately terminated the app domain (and thus, often the process) in which it occurred. While this is a very conservative behavior, it does not provide for proper fault isolation, which would enable the client ...