>That exactly the approach I built with a sample code to query our Web Service. So, either in your case or from what I built, a customized error handler to handle those items should be implemented. As far as I understand, if I would call a method to FoxCentral with an invalid ID, this would result in a COM error to be thrown right away assuming I wouldn't use your client which includes the wrapper.

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.).

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.

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.

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.

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.

>So, basically, does this mean that providers of Web Services usually include a sample code to deal with that instead of just letting the user to figure it out by themselves? This would then bring the issue of platforms and development environments where users would have to convert the sample code to fit their own platforms and development environments.

No, not really. If you're using SOAP exceptions that should be considered the standard for throwing exceptions. It requires code, but it'll be the same sort of code everytime so it's easy to encapsulate.

It's just like any technology - it looks really easy. The devil is in the details in making it reliable especially in an environment such as SOAP where things are can be by architecture flaky.


>Because, for example, lets say we call a method which should return a logical. Assuming a validation takes place on the server, we have to return a validation string. The client would expect a logical but we need to return a validation message instead as the process can't be done. In this case, a simple approach to verify if the string is empty won't work as, at base level, we expect a logical. This is how I came up with the COMRETURNERROR approach combined with a client error handler, which is like you wrapper, to deal with that validation message.

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?

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.

+++ Rick ---