>Uhm, sort of. Server side throwing of exceptions is up to the design of the app, but in asking around a bit and thinking of other ways of doing it it seems throwing an exception on the server to pass down to the client is the preferred way to do this even if it is a soft error (like record not found etc.).

Exactly!

>In other languages it's easy to deal with this, because you can try/catch usually around the block and you can then change a value to a NULL or other exepected value if an error does occur. In VFP this means you have to either use an ON ERROR handler or a wrapper class (you can use wwEval for this which wraps this process into an evaluator class) to catch the error and the return the info. WIth a SOAP client type class you can have an error method and pick up the error there set the lError and cErrorMsg properties and check after every call. To me that's the only reliable way to deal with this sort of thing - if you have a wrapper class or method you can then use that to fix up any return values to whatever is needed so you get consistent results back.

Yes, I haven't found any other ways to do it which would make it simplier and/or better.

>If you don't throw exceptions on the server that result in SOAP faults then you have to come up with your own scheme and when it really comes down to I think that a SOAP error is just plain more efficient and provides all the wrappings already - so we might as well use it. In other langugages and .Net in particular this also makes perfect sense because everything throws exceptions - and a SOAP exception is just another exception you can trap for.

I agree.

>One reason that you want this is, let's say for a moment that you return a value to indicate an error condition like an emtpy string. Ok, you now know that the request failed, but you have no idea why. So then the alternative is to pass some structure that also contains the error info (like a small XML fragment etc). I've been there and done that and although not that big of a deal it does add a fair amount of code to every call.

Yes, in order to keep it simple, I prefer to use the COMRETURNERROR approach. One of the benefits of Web Service is the ability to let the client decide on its implementation. So, if we add too much restrictions, it won't be a benefit anymore.

>This is really why with wwSOAP I've gone the proxy route - the proxy is a single method call, but internally all the error handling and parsing is taken care of so that the actual client code really just makes a method call and checks a single flag to see whether the call was successful.

Yes, I understood that. However, it was a good exercise for me to came to the same conclusion with a custom approach of mine. It allowed me to better understand what is going on. I also have something similar, however not as much powerful as yours, but it works.

>I think part of your issue is that you don't have clean return values. If you return an XML document, there's nothing else you can pass back in that same request. But if you return a simple single value, then it's pretty clear what should be returned. If you don't care about error information or the method is unlikely to have error conditions then you can just return the appropriate value. If a hard error occurs it just fails, but that's just my point - you have to handle that hard error anyway, so why not use that mechanism for all errors?

Pretty cool approach

>If people choose to use your wrapper, then great. They get all the benefits of it - otherwise, they're on their own on doing error handling.

Yup