You are developing a client application that consumes a Windows Communication Foundation (WCF) service.
The operation contract is as follows.

[OperationContract]
[FaultContract(typeof(SalesFault))]
string GetSales(string saleId);

The service configuration file contains the following line in the serviceBehaviors section.

<behavior>
<serviceDebug includeExceptionDetailInFaults=”True”/>
</behavior>

A divide-by-zero exception is not being handled by the service.
You need to ensure that the exception is caught in the client application.
Which type of exception should the client catch?

A.
TimeoutException

B.
FaultException

C.
DivideByZeroException

D.
FaultException<SalesFault>

Explanation:
Set IncludeExceptionDetailInFaults to true to enable exception information to flow to clients for debugging purposes.
This property requires a binding that supports either request-response or duplex messaging.

In all managed applications, processing errors are represented by Exception objects.
In SOAP-based applications such as applications, methods that implement service operations communicate
error information using SOAP fault messages. Because applications execute under both types of error systems,
any managed exception information that needs to be sent to the client must be converted from exceptions into SOAP faults.
For more information, see Specifying and Handling Faults in Contracts and Services.

During development, you may want your service to also send other exceptions back to the client to assist you in debugging.
This is a development-only feature and should not be employed in deployed services.

To facilitate debugging development, set the IncludeExceptionDetailInFaults to true either in code or using an application configuration file.

When enabled, the service automatically returns safer exception information to the caller.
These faults appear to the client as FaultException<TDetail> objects of type ExceptionDetail.

Important
Setting IncludeExceptionDetailInFaultsto true enables clients to obtain information about internal service method exceptions;
it is only recommended as a way of temporarily debugging a service application. In addition, the WSDL for a method that returns
unhandled managed exceptions in this way does not contain the contract for the FaultException<TDetail> of type ExceptionDetail.
Clients must expect the possibility of an unknown SOAP fault to obtain the debugging information properly.