Never use a proxy instance after an exception, even if you catch that exception.
Do not use the using
statement on a proxy.
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.16.130.201