0

Has any one got any advice or resources for best practices for handling errors and exceptions from within a webservice.

ie.
How much information needs to be reported back to the client?
Should ALL errors bubble their way back as full blown exceptions?
Is it common/advisable to wrap responses within a class which contains any error information? (i've seen a lot of production level services take this approach)

Thanks guys.

Adam Naylor
  • 6,172
  • 10
  • 49
  • 69
  • Adam, this is an exact duplicate of http://stackoverflow.com/questions/1019141/should-web-services-throw-exceptions-or-result-objects, asked two days ago. – John Saunders Jun 22 '09 at 12:26
  • tsk... well I did the leg work, just goes to show how bad (or hard) the SO search facility is! – Adam Naylor Jun 22 '09 at 12:30

1 Answers1

0

I think it depends on what the clients are expected to be. If it was all internal to me and I was using WCF for everything, then I might opt for exceptions because they are handled automatically and quite easy to deal with.

If I thought I was going to have clients other than myself, especially non .NET clients, then I would go for something far simpler.

If you don't know, then assume that you'll have other clients, because this would be a pain to change, and it's not that bad for the .NET clients.

At a minimum, return some kind of error code and a description. If you aren't expected to handle multiple languages, they can use the description -- if they need another language, they can use the code for looking it up.

Lou Franco
  • 87,846
  • 14
  • 132
  • 192