Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Handling non expected results
Message
From
26/11/2001 17:24:17
 
 
To
All
General information
Forum:
Visual FoxPro
Category:
Web Services
Title:
Handling non expected results
Miscellaneous
Thread ID:
00586062
Message ID:
00586062
Views:
45
While having discussed that issue before, I thought I would ask your opinions to know what you think. Web Services are shipping data across the net to a client. In search call, the client expect to receive a specific content. In most cases, as XML is so widely used now, we will send some XML strings across the wire. Assuming that situation, where the client expect to receive an XML string, those situations may happens:

1. An XML string is being sent. Once received we can convert that into a cursor. We now have a cursor in VFP.

2. The query on the server didn't find a match. Thus, something has to be returned. Various approaches can be used.

3. An unexpected error happened on the server while processing the query, thus, something has to be returned as well to the client.

In a perfect world, when sending a call to retrieve specific data, we would always have some data. So, we will end up with a VFP cursor. But, sometimes, the condition doesn't match any record, thus, we need to return something to let the client know that there is no record. Several approaches can be used:

1. Some will prefer to return an empty string. So, the client will have to make that verification for every call to see if the string is empty. If it is, they can take action. Otherwise, the string can be converted to a cursor.

2. Some will prefer to use the COMRETURNERROR approach to return any validation, status or error message. Thus, the client can use a global error handler to detect those messages instead of making that verification for every call.

3. Others may have other approaches.

But, then again, those who use option number 1 combined with a validation which should take place on the server before processing the request, may face several scenarios:

1. The validation gets thru. An XML string is being returned.

2. The validation is not ok. A string has to be returned to explain the reason.

3. The validation gets thru but there is no record. A string has to be returned to state it.

4. An unexpected error happened on the server. A string has to be returned to state it.

So, basically, for every request, this may imply the following:
LOCAL lcReturnedString
lcReturnedString=MakeMyCall()
IF lcReturnedString=IsThisAnXMLCursor()
   XMLTOCURSOR(lcReturnedString,'Temp')
   BROWSE
   ELSE
   IF LEN(lcReturnedString)=0
      MESSAGEBOX('No record')
      ELSE
      MESSAGEBOX('Validation message')
   ENDIF
ENDIF
Scenario 4 can be handled by an error handler.

So, is this something you are doing for every call that need that type of implementation of you prefer to use the COMRETURNERROR approach and control everything from one location?

I personally prefer to handle all non cursor data by the use of COMRETURNERROR. So, I could use a simple approach for each call:
LOCAL lcReturnedString
lcReturnedString=MakeMyCall()
* If we are here, this is because we have a cursor
Scenario 2,3 and 4 are controlled by an error handler which controls validation, status and error message. The logic is customed at the error handler level to act accordingly. So, if this is a validation or status message, the logic continues as follow otherwise, we log the error, etc.

What are your opinions?
Michel Fournier
Level Extreme Inc.
Designer, architect, owner of the Level Extreme Platform
Subscribe to the site at https://www.levelextreme.com/Home/DataEntry?Activator=55&NoStore=303
Subscription benefits https://www.levelextreme.com/Home/ViewPage?Activator=7&ID=52
Next
Reply
Map
View

Click here to load this message in the networking platform