Geoff a very talented developer, but everyone needs to ask for help from time to time, and design issues are a classic example. First up, Geoff is absolutely correct, exception handing in web-services is special - its not just like calling a method.
Firstly, exceptions don’t really map directly to the SOAP message format, for example SOAP doesn’t really have a concept of a stack trace that can be transferred across the wire in full fidelity – they have a relatively basic SOAP Fault element that goes back in the return message.
You can throw a text-based representation of the exception into the detail to support diagnostics, but if your web-service consumer doesn’t have intimate knowledge of the service what are they going to do with it?
From a web-service consumer point of view there are only a few things that you want to know when you get a fault:
- Was it invalid input – if so, what?
- If it wasn’t invalid input, was it a transient condition?
- Did to rollback cleanly?
Good web-service implementations document explicitly all the error conditions that could occur for an incoming message and publish it somewhere the consumer can get at it, but thats about the only diagnostic information you need.
Repeat after me, my web-service is autonomous, I’ll tell you I’m not feeling well (error codes) but I won’t bend over so you can take my temperature (passing back stack traces). Is that colourful enough? 