Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

WCF - Throw an Exception or FaultException?

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?

like image 650
michael Avatar asked May 19 '11 16:05

michael


People also ask

What is a FaultException?

Fault exceptions are triggered when the processor detects an error such as the execution of an undefined instruction, or when the bus system returns an error response to a memory access.

What is difference between communication exception and FaultException in WCF?

They're not same. In a WCF service, if it throws an exception inside the service, the client will not get the details. In order to get the formatted exception details on client side, you need to use FaultException instead to let the client know the details. The FaultException information can be serialized as expected.

Which type of behavior should be configured to return exception detail from WCF service?

We can use FaultException &/or FaultContract (in System. ServiceModel namespace) to these exception details to the client.

Which of the exception does WCF throw?

Expected exceptions from communication methods on a WCF client include TimeoutException , CommunicationException , and any derived class of CommunicationException . These indicate a problem during communication that can be safely handled by aborting the WCF client and reporting a communication failure.


2 Answers

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).

like image 118
Ethan Cabiac Avatar answered Oct 13 '22 11:10

Ethan Cabiac


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.

like image 40
Sixto Saez Avatar answered Oct 13 '22 13:10

Sixto Saez