WCF - Throw an Exception or FaultException?

Question

What's more efficient? Throwing an exception or throwing a fault... the way I see it is that there's 2 scenarios:

1. An exception occurred and is caught, do you throw that existing Exception or create a new FaultException and throw that?

2. Your own logic (such as username can't be blank) needs to throw an error either as an Exception or FaultException. Which do you choose?

Basically, which way is the best practice way? I ask because I remember reading somewhere about WCF boxing or unboxing exceptions and it costing additional resources and such like... so I guess also, which is the more efficient way?

Headlong

Answer 1

Coming from a WSDL Contract Perspective, each operation can can have at most one response. However, you can define multiple fault contracts, which basically tells a client "Expect either a response defined by DataContractX, or a fault response defined by FaultContractY or FaultContractZ."

Using FaultExceptions allows you finer control over how your WSDL is represented (or in writing a compliant service against an already defined WSDL).

If you are truly attempting to achieve interoperability and are fully leveraging wsdl and soap to achieve this you will need to use FaultExceptions. If you are using WCF in a .NET only interaction you can use Exceptions or Fault Exceptions, I don't think the performance difference will be significant (Communicating over the network is order of magnitudes more significant than the WCF runtime wrapping Exceptions into a Generic Fault for transmission over the wire).

Boiled

Answer 2

It can depend on where and how you want the exception handled. A client (regardless of platform) will always receive a soap fault exception whether the service code allows for unhandled exceptions, the service explicitly throws a FaultException or throws the generic version of FaultException.

Whether you want to define custom fault exceptions to make it easier to identify specific service conditions is a design concern. My rule of thumb is to only throw custom faults when I expect the client to perform alternate logic triggered by that custom fault. Something like validation is a grey area because you really don't want all your detailed validation logic to be driven by custom faults. I generally create a single custom validation failed fault and have it include all the validation issues it can find as list property of the custom fault.

Handling exceptions is always a costly process but there is no real performance difference between throwing a FaultException or any other .NET exception on the service side.

Aplanatic

Answer 3

From my understanding if you are using wsHttpBinding and if you throw a .Net exception rather than a FaultException the Server-Client channel will be at faulted state, and the proxy class object will have to be recreated as the existing proxy object will be unusable. So the best practice might be to use FaultException.

Fledge

Answer 4

If you simply throw an exception using 'Exception', WCF service will raise FaultExceptionin behind and the root cause of exception will never be known by client unless you mention <serviceDebug includeExceptionDetailInFaults="true"/> in web.config. If you wish client to know the reason/custom message behind the exception, prefer FaultException. It's a best practice to have straggly typed exception.

Sanies