If an exception is thrown in my web service and I wanted to give the user a more meaningful error message rather than a generic 'an error has occurred when processing your request', what are some possible techniques that can be used to pass the exception message back to the client?
is this something that is acceptably practiced?
I've written web services where the response always includes a numeric status code (0 indicates success, non-zero indicates a problem of some type) as well as a text status message. If an error occurred (non-zero status code) then the status message includes a description of the problem, otherwise it is blank. The service also returns a bunch of data depending on what method the user is calling. It seems to work well for our clients. The important thing is to document the behavior so that clients know what to expect and the interface is consistent.
If the error is from your inner code .NET will wrap your inner exception in a SoapException and return it to the user. The JavaScript can look for the soapexception xml element and do something with it. The SoapExceptions message will be the same as the actual exception so you might want to catch it up top and throw something nicer, and without the stack trace.
You can then give the clients a list of possible SoapExceptions.