0

My question is around Error handling in a WCF service and passing error information back to the calling client. I do know that we can use the FaultContract as part of the ServiceContract while defining the interface. What if i dont want to use the FaultContract and as part of my DataContract response i include the Error response or success response as an object of type Result?

What is the difference in the two approaches? Especially in terms of internally any extra channels used?

I have tried both approaches and both work. What i know so far is that approach 2, does not need the client to know what error to trap, he can just investigate the Result object to see.

Example of a FaultContract Code

public interface ICalculator
{
    [OperationContract]
    [FaultContract(typeof(MathFault))]
    int Divide(int n1, int n2);
}

My Error Handling Code

public interface ICalculator
{
    [OperationContract]
    Result Divide(int n1, int n2);
}

[DataContract]
public class Result 
{
    [DataMember]
    public bool Success { get; set; }
    [DataMember]
    public string ErrorNumber { get; set; }
    [DataMember]
    public string ErrorMessage { get; set; }
 }
lloydom
  • 377
  • 2
  • 11
  • I went through the other link. one thing i did not understand is how error raising through faultcontract not expensive? – lloydom Feb 06 '13 at 08:41
  • I think the rationale is, that even though some people consider exception throwing/handling more expensive than return codes, in the context of services (where you have other factors like network latency, processing overhead, etc.) this is even more negligible than in "normal" applications. So in summary, it is not a performance-wise decision. – Christian.K Feb 06 '13 at 08:55

0 Answers0