0

I have a WCF service and I have a FaultContract. I have a Reason in the FaultContract so I have something like this.

FltInfo.Reason = "This is a test";
throw new FaultException<FaultInfo>(FltInfo, new FaultReason(FltInfo.Reason));

Obviously, you see I have the FaultInfo class defined for my data contract. But what would I need to do or how would I do it if I want to get like the fault code, details, or a level (criticality type) aspect with it?

If I didn't include some of those would I still get a soap fault message?

Also, wouldn't the triggering of the faultexception from a TRY-CATCH (or what have you) terminate the communication in the send/receive aspect? Meaning if I have 1 message coming through the receive and that 1 message has a list of let's say 100 items (an array for instance), if I am processing through the array of 100 and I get to let's say the 30th item but it triggers the fault. Would I not lose everything (all 100) because a response was never done and only a fault?

Thanks

user2887486
  • 79
  • 10

1 Answers1

1

You can add the fault code,et using the various constructors of fault exception. And yes, if you leave them blank, you will get WCF default values. You are additionally correct that if you throw a fault exception when processing a single item in the list you will break out of the normal path and will return just your fault.

You can modify this by including your response type in part of the fault and some how marking a single part as invalid. Or your service can have a wrapper response type that allows you to mark specific parts of the data returned as invalid it it makes since to do so in your solution.

joshholl
  • 59
  • 1
  • I'm decided I'm working the data related errors not as faults or exceptions, per say. I have more of the critical system items throwing the faultcontract. Albeit, depending upon the system it may not deliver that faultcontract. (e.g. Network issue, Communication issue, etc). Does that sounds like an appropriate tact? – user2887486 Oct 25 '13 at 02:07
  • sounds similar to how i handle them in our production systems. Faults are thrown for major critical issues, error responses are returned from data/state errors. I think your choices sounds appropriate to me. – joshholl Oct 25 '13 at 05:32