More than halfway through the web-service project I am currently working at, my customer decided to inform me just now that I can’t ever throw exceptions to client applications. The question is that until now I was throwing FaultException exceptions everytime there was a validation, database or any other kind of error. I will clearly need to change this behavior without further questions, but the problem is that I don’t really know what to replace it for. The service has 4-5 endpoints which return different DataContract structures, so I thought about designing a base class having a boolean (indicating failure or success) and object (which I would use to send the serialized exceptions if they are to be thrown) fields and make all the other DataContracts inherit from this structure. But I am not really sure this is the best option. What do you advise me to do?
More than halfway through the web-service project I am currently working at, my customer
Share
This requirement is probably due to the fact that Silverlight consumers are supposed to access the service which can’t handle those exceptions in a proper way unless they switch to the http client stack (which comes with its own drawbacks).
We’ve solved the problem by including a Fault out parameter in every service method signature that needs to be checked by the client. It really sounds worse than it is in practice.