3

Ok, I know I am missing something here. I have the following operation contract:

public double DivideByZero(int x, int y)
{                   
    if (y == 0) 
    { 
        throw new FaultException<ArgumentException>
          (new ArgumentException("Just some dummy exception")
          ,new FaultReason("some very bogus reason"), new FaultCode("007"));
    }
    return x / y;
}

And following is taken from the client:-

  Console.WriteLine("Enter the x value");
  string x = Console.ReadLine();
  Console.WriteLine("Enter the Y value");
  string y = Console.ReadLine();
  try
  {
      double val = client.DivideByZero(Convert.ToInt32(x), Convert.ToInt32(y));
      Console.WriteLine("The result is " + val.ToString());
  }
  catch(FaultException<ArgumentException> exp)  
  {
      Console.WriteLine("An ArgumentException was thrown by the service "+ exp.ToString());    
  }
  catch (Exception exp)
  {
      Console.WriteLine(exp.ToString());
  }

In the above case catch(FaultException exp) (the first catch block with ArgumentException in the client code) block does not get executed. However, when I remove ArgumentException to have catch(FaultException exp), the same catch block gets executed. I am not sure about this as I am throwing FaultException from my operation contract. Am I missing anything here.

Appreciate your help, Ashish

EDIT :- When I updated the service reference in my client, I was able to catch the FaultException<ArgumentException> exception.

Ashish Gupta
  • 14,869
  • 20
  • 75
  • 134

2 Answers2

3

Try it with FaultException<DataContract> for some arbitrary data contract type. If you look at the generated code for the fault in the proxy class, I bet you'll see that the ArgumentException is not serializing the way you expect it to.

John Saunders
  • 160,644
  • 26
  • 247
  • 397
  • Absolutely. If you have a custom exception class and use that to throw and catch, It does work. Not sure why it wont work (serialize) with ArgumentException. – Ashish Gupta Jun 13 '10 at 13:20
  • 1
    @Ashish: there is no reason for `Exception` to serialize using the DataContractSerializer. Do not use exceptions as the fault type. They will not appear properly as SOAP Faults to clients. This is not what SOAP Faults are about. – John Saunders Jun 13 '10 at 13:45
  • thanks for the reply. I am very new to WCF and do realize now that you probably would use your custom exception class as DataContract rather than using the system "Exception" (or its classes). – Ashish Gupta Jun 13 '10 at 13:54
  • @Ashish: also, did you declare your faults using `[FaultContract]`? – John Saunders Jun 13 '10 at 13:57
  • I did. Also, now I am looking at it and see that FaultException does work when I updated the service reference. – Ashish Gupta Jun 13 '10 at 14:13
0

If you are deriving Exception class, make sure that your custom exception has the serialization constructor

protected MyCustomException(
          SerializationInfo info,
          StreamingContext context)
            : base(info, context) { }
John Saunders
  • 160,644
  • 26
  • 247
  • 397
Alexandre
  • 7,004
  • 5
  • 54
  • 72