Section C.7. Faults

C.7. Faults

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

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

3. Use the FaultContractAttribute 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); 

   
   

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

5. 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 {...} 

   
   

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

7. Consider using the ErrorHandlerBehaviorAttribute on the service for both promoting exceptions to fault contracts and automatic error logging:

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

   
   

8. Consider using the CallbackErrorHandlerBehaviorAttribute on the callback client for both promoting exceptions to fault contracts and automatic error logging:

    [CallbackErrorHandlerBehavior(typeof(MyClient))] public partial class MyClient : IMyContractCallback {    public void OnCallabck( )    {...} }