Planned and Unplanned Exceptions in WCF
| Retired Content |
|---|
The Web Service Software Factory is now maintained by the community and can be found on the Service Factory site. This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. Retired: November 2011 |
Exceptions can be planned and unplanned. However, exceptions should not be used to control business logic. In other words, exceptions should be used only for exceptional situations where processing a request cannot continue.
Planned Exception Scenario
As you can imagine, client applications using your WCF service might not pass parameters that are required by the operation. You want your system to return a safe and friendly message that the client application can respond to. As a result, the recommendation for planned exceptions is to define a custom fault contract in WCF that will return this message to the client application. For information about handling known faults in WCF, see How to: Return Custom Error Messages Using FaultContracts.
Unplanned Exception Scenario
You cannot possibly know and plan for all the potential ways that your code may generate an exception. However, you probably want to know when an unexpected exception occurs, and you may want to pass a generic, sanitized exception back to the client application. For internal client applications within an organization, you may also want to return the exception that was caught. WCF provides several approaches for you to handle these situations:
- You can catch a managed exception in a try/catch block and return that exception to the client application within a FaultException<T> generic type. For information about wrapping exceptions in a fault exception, see How to: Wrap Managed Exceptions in a FaultException.
- You can catch a managed exception in a try/catch block and return a generic, sanitized fault to the client application using a FaultContract. For information about the use of fault contracts, see How to: Return Custom Error Messages Using FaultContracts.
- You can customize how your services intercept errors, perform processing, and report errors to the client application.
To extend control over error handling and error reporting in WCF so that your services can intercept errors, perform processing, and affect how errors are reported to the client application, implement the IErrorHandler and IServiceBehavior interfaces. The following list describes these interfaces:
IErrorHandler. This interface in the System.ServiceModel.Dispatcher namespace allows you to explicitly control the SOAP fault that is generated and determine whether to send it back to the client application, and, optionally, perform custom error processing, such as logging. It consists of the following two methods:
- ProvideFault. This method allows the fault that is reported for an error to be replaced or suppressed.
- HandleError. This method allows error processing to take place in the event of an error and it controls whether additional error handling can execute.
IServiceBehavior. This interface in the System.ServiceModel.Description namespace provides a mechanism to modify or insert custom extensions across an entire service. It consists of the following methods:
- ApplyDispatchBehavior. This method provides the ability to change run-time property values or to insert custom extension objects, such as error handlers.
- AddBindingParameters. This method provides the ability to pass custom data to binding elements to support the contract implementation.
- Validate. This****method provides the ability to inspect the service host and the service description to confirm that the service can successfully run. For example, you can enforce that the contract have a SOAP fault with a specific DetailType.
These interfaces allow you to explicitly control the behavior of an application when it throws a FaultException. You can also log exceptions in the event log to record them for tracking and later analysis. For information about handling unknown faults in WCF, see How to: Configure Support for Unhandled Exceptions.