tags:

views:

153

answers:

1
+2  Q: 

wcf faults

Hello, and thanks for any assistance.

I'm confused on how I should return errors to a client using SOAP.

I have a wcf service, but I'm not sure what technology the client is using, so I'd like to stick to the SOAP specification.

As far as I've read, Fault messages seem to be the best way to handle this.

I can see my service having many different possible faults:

Null\expected data errors Data format errors (ie: db only allows 3 chars) Data Range errors "Customer already exists", "Unable to process your request" type errors

Would it be proper to create a new object for each of those faults?

and throw as such:

FaultException(nf);
FaultException(idf);
FaultException(af);
FaultException(rf);

The client is passing in big objects with many properties to practically every method (ie: Customer, Order, ext.)

Would this be the proper way of handling errors and sending back to the client?

It seems out of place to have to add each fault to the attributes above the method?

IE:

[OperationContract]
[FaultContract(typeof(NullFault))]
[FaultContract(typeof(InvalidDataFault))]
[FaultContract(typeof(ArguementFault))]
[FaultContract(typeof(RangeFault))]
void CreateCustomer(Customer customer);

(also, what about a GenericFault? How would you handle business rule errors? ie: Customer already exists, to many line items, don't ship to that area, payment method not accepted, ext.?)

Please let me know if this method is proper or if there is another excepted solution and how you would handle the 'business rule' situation.

Thanks, Steven

+2  A: 

Returning a Fault is the correct way to do it in general, but you should also ask yourself what the client program is going to do with the information you return in a fault. If the client only needs to know that a fault happened then all you need is a single fault. That fault could include message text that the client could display to its user.

If the client needs to take different action based on whether it's a NullFault or a RangeFault, then that's when you need separate faults. But if there's no difference between one and another, then save yourself and the client programs some time and effort and only define a single fault.

John Saunders
Thanks John for your response.I quick followup question:If you were to go with the single fault way, do you think it would be a good idea to create an enum property of the fault type (ie: NullReference, Range, InvalidData, BusinessRule, Other)?Do you know if this enum also be passed in the soap message?Thanks, Steven
stevenrosscampbell
You could return such an enum, but keep in mind that your clients will have to look at that information and do something with it. If they're not going to do something programmatic with the information you send them, then don't send it.
John Saunders
Yes, I agree. I guess all I can do is tell them about it and hope they use it accordingly. Thanks, Steven
stevenrosscampbell