Programming WCF Services, 2nd Edition

Faults

1. Never use a proxy instance after an exception, even if you catch that exception.

2. Avoid fault contracts and allow WCF to mask the error.

3. Do not reuse the callback channel after an exception even if you catch that exception, as the channel may be faulted.

4. Use the FaultContract attribute with exception classes, as opposed to mere serializable types:

   //Avoid:
   [OperationContract]
   [FaultContract(typeof(double))]
   double Divide(double number1,double number2);
   
   //Correct:
   [OperationContract]
   [FaultContract(typeof(DivideByZeroException))]
   double Divide(double number1,double number2);

5. Avoid lengthy processing such as logging in IErrorHandler.ProvideFault( ).

6. With both service classes and callback classes, set IncludeExceptionDetailInFaults to true in debug sessions, either in the config file or programmatically:

   public class DebugHelper
   {
      public const bool IncludeExceptionDetailInFaults =
   #if DEBUG
         true;
   #else
         false;
   #endif
   }
   [ServiceBehavior(IncludeExceptionDetailInFaults =
                    DebugHelper.IncludeExceptionDetailInFaults)]
   class MyService : IMyContract
   {...}

7. In release builds, do not return unknown exceptions as faults except in diagnostic scenarios.

8. Consider using the ErrorHandlerBehavior attribute on the service, both for promoting exceptions to fault contracts and for automatic error logging:

   [ErrorHandlerBehavior]
   class MyService : IMyContract
   {...}

9. Consider using the CallbackErrorHandlerBehaviorAttribute on the callback client, both for promoting exceptions to fault contracts and for automatic ...