Faults
Never use a proxy instance after an exception, even if you catch that exception.
Do not reuse the callback channel after an exception even if you catch that exception, as the channel may be faulted.
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);Avoid lengthy processing such as logging in
IErrorHandler.ProvideFault( )
.With both service classes and callback classes, set
IncludeExceptionDetailInFaults
totrue
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
ErrorHandlerBehaviorAttribute
on the service for both promoting exceptions to fault contracts and automatic error logging:[ErrorHandlerBehavior] class MyService : IMyContract {...}
Consider using the
CallbackErrorHandlerBehaviorAttribute
on the callback client for both promoting exceptions to fault contracts and automatic error logging:[CallbackErrorHandlerBehavior(typeof(MyClient))] public ...
Get Programming WCF Services now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.