At 01:51 PM 6/3/2004, you wrote: >Not in my situation. For example UPS' webservice. If you supply a id number that is >not in the correct type, it returns to you an xml file similar to below. > ><error> > <errorCode>1</errorCode> > <errorMessage>You have supplied an invalid id number</errorMessage> ></error>
I see. UPS, though, has chosen not to use SOAP faults, which IMHO, makes it harder for the SOAP client to handle exceptions. This is not a true SOAP webservice. SOAP is meant to offer remote method invocation, and UPS isn't really offering this. As for returning an error in the same "type" as the "return type", I've never seen this before. How could a client know how to process the error? Say the return type is a struct. What do you do, put the error type as the key name and the error message as the key value? This would work, but then what about an Array return type? What do you do, comma delimit the error type and message and make the string the only element in an array. You see what I'm getting at....there is no consistency with that approach. >If I had a service like below you can't return an error like that because if you >invoke this with a customerIDNumber that is a string and not numeric the error is >displayed to screen and not caught in the method. You could wrap all calls to the service in a "facade" CFC that CFTRYs to invoke the requested service and CFCATCHes exceptions, translates them, and return and nice little XML message? -- Alex ---------------------------------------------------------- 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]
