1

The main parameter to my Service's OperationContract is a class called Preapproval. In the Preapproval class, there are a few public getters/setters for the DataMember attributes. I have code that validates the input to the setters, such that I would throw an ArgumentException, if say, a parameter is blank or out of the proper bounds for the domain.

If the inputs are invalid, I usually would throw an ArgumentException here. Since this is a WCF situation, must I throw a pre-defined FaultException here rather than ArgumentException? I understand that, elsewhere, I may catch general exceptions and rethrow them as FaultExceptions, but this activity will occur higher up the stack, in some work performed automatically by WCF plumbing.

For example, when a caller invokes my service, the serializer will deserialize their SOAP, attempt to call the setters on my object, and experience the throwing of the ArgumentException, way before my operation is actually invoked. Thus, is it good design practice, in DataContract classes, to simply throw FaultExceptions right away? I really don't want to wire a custom handler up to the channel dispatcher.

I understand that I could simply throw FaultExceptions directly, but I would really like to confine that sort of thing to the service. If it cannot be avoided, I can do it in the supporting classes as well, but I would prefer to write typical code as much as possible, that is not so tightly coupled to System.ServiceModel, etc.

Thanks!

Pittsburgh DBA
  • 6,672
  • 2
  • 39
  • 68
  • How about using the [FaultContractAttribute](http://msdn.microsoft.com/en-us/library/system.servicemodel.faultcontractattribute.aspx)? – Brad Christie Mar 29 '11 at 16:49
  • Naturally, that is an option that we are exploring. My question is more along the lines of best practices. For example, in the class which we are using as a service parameter, in its setters, if we must throw exceptions, should we throw FaultException, there also, rather than ArgumentException? Generally, we would prefer to couple as few things to the WCF framework as possible, but seeing as how these are marked with DataContract and DataMember attributes, perhaps that point is moot. – Pittsburgh DBA Mar 29 '11 at 17:53
  • If anyone reads this, I have decided to take a simpler approach, and merely pass primitive typed parameters to the service, rather than the Preapproval object. This way, the service itself may validate the input and throw the appropriate FaultException. The EAB has turned out to be overkill here for this one-method service. – Pittsburgh DBA May 09 '11 at 20:15

2 Answers2

3

I would leave the FaultExceptions out of your DataContract class -- you might want to use those classes outside of a WCF context.

One approach that would prevent WCF specific code from sneaking into your DataContracts (besides attributes) would be to have the DataContract class throw exceptions and in the service layer use Enterprise Library's WCF Exception Shielding to map those exceptions to fault contracts.

Basically Enterprise Library implements IErrorHandler and converts Exceptions to FaultExceptions. I think a handler is the only way to achieve what you want (since the exceptions are not thrown in your service). The good news is that you really don't have to do much to get it working.

Just add an attribute to your service:

[ServiceContract]
[ExceptionShielding]
public interface IApproval
{
    [OperationContract]
    [FaultContract(typeof(ApplicationServiceFault))]
    [FaultContract(typeof(SystemServiceFault))]
    void PreApprove(Preapproval preapproval);
}

and then add some configuration (configuration omitted to save space) to map Exceptions to a FaultContract. Note that your operations will still have to declare FaultContracts.

Randy Levy
  • 22,566
  • 4
  • 68
  • 94
  • Thanks; this is more aligned with my question, in that we want to keep the classes rather framework agnostic. So, since we are throwing the ArgumentException in the setters, we need a way to insure that this is mapped appropriately. I will look at this Exception Shielding. Thank you. I will update as soon as I get a chance. – Pittsburgh DBA Mar 30 '11 at 13:52
  • This looks like the way to go. I am particularly interested to see how this plays out when invalid parameters are passed to the service. Incidentally, this line of research led me to the Validation Block, which is also a nice feature. Perhaps the two in concert will be the ultimate solution for clean WCF parameter validation. – Pittsburgh DBA Mar 31 '11 at 16:57
  • @Pittsburgh DBA: It will be a bit of a pain to get VAB to work in the model you are talking about. You would probably have to create a ruletset for every property and have each setter call the Validate method. Also, in your current approach if you validate on the setters then as soon as one setter gets an invalid value you will throw an exception so the user will only get one error message at a time. This might not be what users would like to see. – Randy Levy Mar 31 '11 at 22:07
1

Your PreApproval class should not be aware that it's being used in a web service. Let it throw whatever exception it would have thrown if it were being called from any other type of application.

The "top level" of your service should catch exceptions and translate them to the appropriate FaultException.

John Saunders
  • 160,644
  • 26
  • 247
  • 397
  • As I said, this is not feasible, as it is not our code, but rather, WCF internals, that deserialize the callers' SOAP, and thereby invoke the setters on our DataContract class. Perhaps I am not explaining this very well. We can, of course, catch exceptions left and right, and throw the appropriate FaultException. We cannot do this WITHIN the WCF plumbing which executes PRIOR to our service code. – Pittsburgh DBA Mar 30 '11 at 13:51
  • @Pitt: the setters would throw the exception. – John Saunders Mar 31 '11 at 20:37
  • @John Saunders: the setters do throw the exception, and the type of exception they throw is ArgumentException. This is because they are general-use classes, and not tied to WCF dependencies. As such, when the service is invoked, and the setters throw their exceptions, it causes problems because, unless we employ ExceptionShielding, this is occurring too far up the stack for us to catch and subsequently throw a FaultException as we would wish to do. – Pittsburgh DBA May 03 '11 at 16:53
  • Look at implementing the [`IErrorHandler`](http://msdn.microsoft.com/en-us/library/system.servicemodel.dispatcher.ierrorhandler.aspx) interface. This is what it's for. – John Saunders May 03 '11 at 16:56
  • Thank you. Would that be superior to using the Enterprise Exception Handling Application Block? – Pittsburgh DBA May 03 '11 at 18:21
  • @Pitt: for this purpose, I believe so. This allows you to use `[FaultContract]` on your operations. The `IErrorHandler` would translate the original exception into the correct fault. – John Saunders May 03 '11 at 20:57