At 03:01 PM 6/3/2004, you wrote: >Alexander Sherwood wrote: > >>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? > >See my > >>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? > >This may be on option. I haven't thought of that yet. How could I figure out all >possible combos of errors returned from invalid types. I could pass a type differant >than the type attribute to see what the message would be. But I really can't trust cf >to return only those. I've seen some wack errors coming from CF.
The nice thing about the facade method is that you can call your service natively (CFOBJECT, CFINVOKE TYPE="COMPONENT") within the facade CFC an not have to deal with SOAP faults yourself. This should make trapping CF's errors easier, not to mention cutting down on the number of WSDL files you'll need to publish! You could use the type="" attribute of CFCTACH to isolate the type of error throws when invalid arguments are passed. You could then hard code this type as your own custom "invalid argument" type and return this to the client. The beauty is that you can then trap other errors not related to invalid arguments and return customized errors to the client as well. Hope this helps. -- 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]
