If it's a query it has two columns. (errorCode, errorMessage)
If it's a string it returns an xml string with an errorCode and errorMessage branches.
If it's a struct it returns an errorCode and errorMessage key.
If it's an array it returns an array position 1 for the errorcode and position 2 for the errormessage.
If it's numeric is returns the errorcode.
I actually think this is a terrible idea from an API design point of view... Merging failures with real data is always problematic. Consider, in particular, your numeric return: how can the client differentiate between an error return and a valid return? In the array case, what happens if a valid return is arr[1] numeric and arr[2] string? It makes handling the result very fiddly and error-prone.
If you really, really must merge error information with real results, you would be much better off to define a suitable result structure and always use that, e.g.,
... returntype="struct" ...
<cfset var result = structNew() />
<cfset result.success = true />
...
<cfif someErrorOccurred>
<cfset result.success = false />
<cfset result.errorCode = xxx />
<cfset result.message = "something broke" />
<cfelse>
<cfset result.data = theRealResult />
</cfif>
<cfreturn result />Now your client code always looks like this:
<cfset r = ws.callMethod(...) />
<cfif r.success>
... process r.data ...
<cfelse>
... process r.errorCode / r.message ...
</cfif>Sean A Corfield -- http://www.corfield.org/blog/
"There are no solutions, only trade-offs." -- Thomas Sowell
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email
to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com).
An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
