Never use a proxy instance after an exception, even if you catch that exception.
Avoid fault contracts and allow WCF to mask the error.
Do not reuse the callback channel after an exception even if you catch that exception, as the channel may be faulted.
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);
Avoid lengthy processing such as logging in IErrorHandler.ProvideFault( )
.
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 {...}
In release builds, do not return unknown exceptions as faults except in diagnostic scenarios.
Consider using the ErrorHandlerBehavior
attribute
on the service, both for promoting exceptions to fault contracts and for automatic error
logging:
[ErrorHandlerBehavior] class MyService : IMyContract {...}
Consider using the CallbackErrorHandlerBehaviorAttribute
on the callback client, both for
promoting exceptions to fault contracts and for automatic error logging:
[CallbackErrorHandlerBehavior(typeof(MyClient))] class MyClient : IMyContractCallback { public void OnCallabck( ) {...} }
3.14.252.56