Summary:

• FaultExceptions don’t fault the channel. All other unhandled exceptions fault the channel. It doesn’t matter what is there in the FaultContract, or if there is even one.
• When you are doing development, set includeExceptionDetailInFaults equal to true on server. On client catch FaultException<ExceptionDetail> e. All the information (e.g., stack trace on server) can be obtained by examining e.Detail.
• In production, you will set includeExceptionDetailInFaults equal to false.
• If service throws a FaultException<T>, it will reach the client as a FaultException<T> no matter what is there in the contract. However, if the service does not apply a FaultContract(typeof(T)) attribute to the service method, client has no way of knowing that a FaultException<T> can occur. T can be anything that WCF can serialize.
• All unhandled exceptions translate into a FaultException on client.
• Say you apply a FaultContract(typeof(DivideByZeroException)) and your method throws a DivideByZeroException. Client gets a FaultException. If you want the client to get a FaultException<DivideByZeroException> you have two options:
  • catch the DivideByZeroException and instead throw a FaultException<DivideByZeroException>.
  • use Juwal Lowy’s PromoteException helper method in his ServiceModelEx library to automagically transform the returned SOAP message so that client in fact gets a FaultException<DivideByZeroException>.