Allows an implementer to control the fault message returned to the caller and optionally perform custom error processing such as logging.
Assembly: System.ServiceModel (in System.ServiceModel.dll)
Thetype exposes the following members.
|HandleError||Enables error-related processing and returns a value that indicates whether the dispatcher aborts the session and the instance context in certain cases.|
|ProvideFault||Enables the creation of a custom FaultException<TDetail> that is returned from an exception in the course of a service method.|
To explicitly control the behavior of the application when an exception is thrown, implement the interface and add it to the Dispatcher’s ErrorHandlers property. enables you to explicitly control the SOAP fault generated, decide whether to send it back to the client, and perform associated tasks, such as logging. Error handlers are called in the order in which they were added to the ErrorHandlers property.
Implement the ProvideFault method to control the fault message that is returned to the client.
Implement the HandleError method to ensure error-related behaviors, including error logging, assuring a fail fast, shutting down the application, and so on.
Because the HandleError method can be called from many different places there are no guarantees made about which thread the method is called on. Do not depend on HandleError method being called on the operation thread.
All ProvideFault implementations are called first, prior to sending a response message. When all ProvideFault implementations have been called and return, and if fault is non-nullptr, it is sent back to the client according to the operation contract. If fault is nullptr after all implementations have been called, the response message is controlled by the ServiceBehaviorAttribute::IncludeExceptionDetailInFaults property value.
Exceptions can occur after all ProvideFault implementations are called and a response message is handed to the channel. If a channel exception occurs (for example, difficulty serializing the message) objects are notified. In this case, you should still make sure that your development environment catches and displays such exceptions to you or makes use of tracing to discover the problem. For more information about tracing, see Using Tracing to Troubleshoot Your Application.
After the response message has been sent, all HandleError implementations are called in the same order.
Typically, an implementation is added to the ErrorHandlers property on the service (and the client in the case of duplex communication).
You can add the to the runtime by implementing a behavior (either an System.ServiceModel.Description::IServiceBehavior, System.ServiceModel.Description::IEndpointBehavior, System.ServiceModel.Description::IContractBehavior, or System.ServiceModel.Description::IOperationBehavior object) and use the behavior programmatically, from a configuration file or with a custom attribute to attach your .
For more information about using behaviors to modify the runtime, see Configuring and Extending the Runtime with Behaviors.
The following code example demonstrates a service that implements that returns only FaultException<TDetail> of type GreetingFault when a service method throws a managed exception.
The following code example shows how to use a service behavior to add the implementation to the ErrorHandlers property.
The following code example shows how to configure the service to load the service behavior using an application configuration file. For more details about how to expose a service behavior in a configuration file, see IServiceBehavior.
<configuration> <system.serviceModel> <services> <service name="Microsoft.WCF.Documentation.SampleService" behaviorConfiguration="metaAndErrors"> <host> <baseAddresses> <add baseAddress="http://localhost:8080/SampleService"/> </baseAddresses> </host> <endpoint address="" binding="wsHttpBinding" contract="Microsoft.WCF.Documentation.ISampleService" /> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service> </services> <behaviors> <serviceBehaviors> <behavior name="metaAndErrors"> <serviceDebug includeExceptionDetailInFaults="true"/> <serviceMetadata httpGetEnabled="true"/> <enforceGreetingFaults /> </behavior> </serviceBehaviors> </behaviors> <extensions> <behaviorExtensions> <add name="enforceGreetingFaults" type="Microsoft.WCF.Documentation.EnforceGreetingFaultBehavior, HostApplication, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null" /> </behaviorExtensions> </extensions> </system.serviceModel> </configuration>
Windows 8.1, Windows Server 2012 R2, Windows 8, Windows Server 2012, Windows 7, Windows Vista SP2, Windows Server 2008 (Server Core Role not supported), Windows Server 2008 R2 (Server Core Role supported with SP1 or later; Itanium not supported)
The .NET Framework does not support all versions of every platform. For a list of the supported versions, see .NET Framework System Requirements.