Learning WCF

Exceptions and Debugging

When an exception is thrown by the .NET runtime, the executing thread is aborted if it is not caught somewhere in the call chain. In the case of an executing service operation, an uncaught exception will propagate up to the service model. The service model treats uncaught exceptions as potential indicators of a serious problem and as such will put the channel into a faulted state. If the executing operation is not one-way, the service model will return a fault to the client. The information included in this fault is influenced by the type of exception and by service debugging behaviors.

In this section, I will focus on how the service model handles uncaught exceptions at the service and client. I’ll also explore configurable service debugging behaviors. First, you will complete a lab to practice working with exceptions.

Lab: Working with Uncaught Exceptions

In this lab, you will open an existing solution that lets you upload photos to a service, similar to the examples used in Chapter 3. The solution has a faulty configuration setting that will cause the business logic to throw an exception. You will explore how exceptions are reported to the client before and after enabling the service debug behavior to report exceptions as faults.

1. Open the startup solution for this lab, located in <YourLearningWCFPath>\Labs\Chapter8\Exceptions\Exceptions.sln. This solution includes the following projects: ContentTypes, FileManager, LinkItems.Dalc, PhotoManager, PhotoManagerService ...