Programming WCF Services, 3rd Edition

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 to keep functioning even after the object blew up. Much the same way, after any unhandled error on the client side, the object would go down with the ship. Developers that did not like this had to provide for process (or app domain) isolation between the client and the object, which greatly complicated the programming model. That is not the WCF behavior, however. If a service call on behalf of one client causes an exception, it must not be allowed to take down the hosting process. Other clients accessing the service, or other services hosted by the same process, should not be affected. As a result, when an unhandled exception leaves the service scope, the dispatcher silently catches and handles it by serializing it in the returned message to the client. When the returned message reaches the proxy, the proxy throws an exception on the client side. This behavior provides every WCF service with process-level isolation. The client and service can share a process, and yet be completely isolated as far as errors. The only exceptions that will take down the host process are critical errors that blow up .NET itself, such as stack overflows. Fault isolation, however, ...