Learning WCF

Chapter 8. Exceptions and Faults

Leading up to this final chapter in the book, you have learned how to design service contracts, configure bindings, choose a hosting environment, and select platform features for instancing and concurrency, reliability, and security. Although I have touched on exceptions and faults that may occur in different scenarios, this chapter will focus solely on the exception-handling semantics built-in to WCF.

Component-oriented programming models traditionally rely on exceptions to communicate problems encountered during execution flow. The .NET framework offers structured exception handling for exceptions to be caught, handled, thrown, or otherwise ignored and propagated automatically up the call chain. At some point, if an exception goes unhandled to the top of the call chain, something has to give—and that’s when the .NET runtime terminates the executing thread. To prevent this abrupt termination, one of the callers in the chain has to trap the error—which usually means logging it, reporting it to the user, or otherwise correcting the problem.

In a distributed system, exceptions that occur remotely must traverse process or machine boundaries before they reach the client. In an SOA, the boundary is a service boundary, which may be located in the same process or across process or machine boundaries. Beyond these distribution boundaries, there may also be technology and platform boundaries, which require interoperable communication. As discussed in Chapter 1 ...