3

I'm designing a WCF service that will return a response code (such as 0 for success, or another number for errors). Also, all methods of the web service will perform several common validations (such as authenticating an apiKey).

I am wondering if there is a best practice approach or organizing and retrieving these response codes and messages.

Thanks for any suggestions.

dotariel
  • 1,584
  • 12
  • 23

2 Answers2

9

Ideally, don't use response codes. Return something usable on success (or void) and throw an exception on failure.

People deal with exceptions. We often forget to look at returned codes, especially when 99% of the time it's success, and we don't care about any response. So we don't capture. Then we don't bother checking for failure. Then we spend 2 days tracking down a bug that we can't find because no exception was thrown and we have no idea where the 600,000 line application failed that used your webservice... we don't even know it was a call to your webservice that failed. Just that some data is wrong for some unknown reason.

There's a topic on SO about this: Which and Why do you prefer Exceptions or Return Codes

Community
  • 1
  • 1
CaffGeek
  • 21,856
  • 17
  • 100
  • 184
  • 1
    Chad, this makes a lot of sense. However, can exceptions be thrown from a web service without knowing what platform the service is being consumed from? My initial thought was to establish a DataContract that encapsulates a code and a message. How would this be replaced with an exception? – dotariel Sep 10 '10 at 21:31
  • 1
    @XSaint32, can't say I've done it much, but I don't think it's an issue. I'm pretty sure I have a .NET app calling a Java service, and it catches exceptions without an issue. The result is ultimately going to be serialized to xml/soap. The generated classes that are made when you add a webservice reference handle this as far as I can tell. – CaffGeek Sep 10 '10 at 21:55
  • this approach will work with the the xml/soap wrapper, but I may need to provide these services using REST. Would a RESTful service be able to throw anything other than an HTTP exeption? I am required to assume that the client consuming the web service could be a simple PHP cURL site. – dotariel Sep 11 '10 at 00:45
2

Don't use return codes directly. Return codes usually mean success, set of expected fails and unexpected fail. Web services replace this mechanism with expected faults and unexpected faults. Check FaultContract and FaultException<T> for implementation details for expected faults. Unexpected fault is any other exception. That is the best practice.

Ladislav Mrnka
  • 360,892
  • 59
  • 660
  • 670