RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Using the Exception Handling Block in Enterprise Library 3.0 : Page 4

Give your applications seamless and reusable error handling and logging services with the powerful toolset from Enterprise Library 3.0.

Using the Exception Handling Block with WCF Services
WCF services are slightly different than desktop applications. When an exception occurs in a WCF service, the WCF service propagates that exception back to the caller. For a plain WCF service, you specify a fault contract that determines the exception information propagated back to the caller. By decorating the service operation with a fault contract attribute, you can specify that the operation will return a fault of a particular type.

The Exception Handling block shields a WCF service from disclosing information about its internal implementation when an exception occurs. To use the Exception Handling block with a WCF service, following this procedure:

  1. Using the Add Reference option, import the Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.WCF.dll assembly to your WCF service project.
  2. Create a data contract that acts as a placeholder for storing details about the exception.
  3. Configure a WCF shielding policy in the <exceptionPolicies> section of the configuration file.
  4. Decorate the service interface with the [ExceptionShielding] attribute.
  5. Decorate the service operation with the [FaultContract] attribute, and supply the name of the data contract class created in step 2.
Here's a detailed example. First, create a data contract class named WCFServiceFault with two properties: a string property named FaultMessage and a GUID property named FaultID.

   using System;
   using System.Runtime.Serialization;
   public class WCFServiceFault
      private string _faultMessage;
      private Guid _faultID;
      public string FaultMessage
         get { return _faultMessage; }
         set { _faultMessage = value; }
      public Guid FaultID
         get { return _faultID; }
         set { _faultID = value; }
Next, add the WCF Exception Shielding policy as a child element of the <exceptionPolicies> element.

   <add name="WCF Exception Shielding">
     <add type="System.InvalidOperationException, mscorlib, 
      Version=, Culture=neutral, PublicKeyToken=
      b77a5c561934e089" postHandlingAction="ThrowNewException" 
       <add type="Microsoft.Practices.EnterpriseLibrary.
        name="DefaultFaultContract Handler" 
         <add name="FaultID" source="{Guid}"/>
         <add name="FaultMessage" source="{Message}"/>
In the configuration shown above, note that the default exception handling policy name is "WCF Exception Shielding." By default, the Exception Handling block looks for this policy name at run time. As you can see from the <exceptionHandlers> section, the exception handler class named FaultContractExceptionHandler implements the WCF Exception Shielding policy by converting the exception to the FaultContract specified in the faultContractType attribute.

Using the <mappings> section, you provide the information to map the exception details to the properties of the WCFServiceContract class. After adding the configuration settings, create a new WCF service named ProductService, and import the Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.WCF namespace.

   using Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.WCF;
Then decorate the service interface and the service implementation classes with the exception handling-related attributes:

   using System.ServiceModel;
   using System.Runtime.Serialization;
   using Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.WCF;
   public interface IProductService
      string GetProductName(int productID);    
   public class ProductService : IProductService
      public string GetProductName(int productID) 
         return "Sample Product";
Note the use of the [ExceptionShielding] attribute that decorates the IProductService class and the [FaultContract] attribute that passes the WCFServiceFault class type as an argument right before the code invokes the GetProductName method.

That's all that's involved in shielding the exception information from the service side. On the client side, when an exception occurs in the service, you'll want to receive a meaningful exception and let the user know what happened. Your code should catch a FaultException<T> where T is the type of FaultContract used. Here's some example client-side code:

      // Call the exception shielding-enabled WCF service method
   catch (FaultException<WCFServiceFault> exception)
      WCFServiceFault fault = exception.Detail;
When the preceding code catches the exception, the Detail property returns the WCFServiceFault object, which contains the FaultID and FaultMessage values. The code displays those in a MessageBox for the user.

That accomplishes the goal of hiding implementation details from users by mapping WCF exceptions to a FaultContract type that you can catch as an exception in the client code.

You've seen some examples of how to use the Exception Handling block for logging, wrapping, replacing, and propagating exceptions in a standard Windows Forms application as well as how to use the Exception Handling block to shield WCF services from exposing sensitive information to clients. Despite the initial complexity of the configuration required to set up this generic exception handling, with a little practice, you'll find Exception Handling block ideal for creating .NET applications that are flexible and easy to maintain.

Thiru Thangarathinam works at Intel Corporation in Chandler, Arizona. He's a Microsoft MVP who specializes in architecting, designing, and developing distributed enterprise-class applications using .NET-related technologies. He is the author of the books "Professional ASP.NET 2.0 XML" and "Professional ASP.NET 2.0 Databases" from Wrox press and has coauthored a number of books on .NET-related technologies. He is a frequent contributor to leading technology-related online publications.
Email AuthorEmail Author
Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date