Interesting observation about finding return codes awkward.
My suggesting about return codes is as a programming technique to handle exceptions rather than cfthrow.
I can see some immediate uses for your cfc, but it would have to be reworked to handle exceptions.
Here is one case.
variables.separator = getPathSeparator(); runs when the CFC is invoked. It calls createObject without any exception handling. If the createoject fails, the application crashes without any opportunity for in-line repair.
At 12:51 PM 10/11/2004, you wrote:
> CF functions and tags do not have return codes. Something I never liked in > CF.
Funny, I have never felt the need for return codes, I actually find them pretty awkward... Well, to each his own :-)
Thanks for your feedback anyway, I appreciate it
---------------------------- Massimo Foti DW tools: http://www.massimocorner.com CF tools: http://www.olimpo.ch/tmt/ ----------------------------
---------------------------------------------------------- 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]
----------------------------------------------------------------------- http://www.switch-box.org/CFSQLTool/Download/
Switch_box MediaFirm, Inc. www.Switch-box.org Loveland, CO USA
----------------------------------------------------------
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]
