Geoff "If there is any chance that the call to the CFC will pass incorrect data types (eg, from some sort of user input) the input validation should be performed upstream -- ie. not in the component."
If this is the case, then what is thr purpose of CFARGUMENT then apart from populating the CFC with metadata? If I have to validate the data and catch the exeption before it goes into the CFC, then why even bother using CFARGUMENT? To me this would be just doubling up on code cause you are validating the data before it goes into the CFC, then using CFARGUMENT to once again validate the data being received by the CFC. "In any event, once you have trapped the error in your CF_ARGUMENT tag, what then? Don't you still have to return a result to the script calling your object, and presumably that script has to do something with the error?" When I trap the error, then I am free to deal with it as I see fit. If I want to display an error to the screen, then I can. If I need to write the error information to a log file, then I can, or even if I just want to return nothing from the CFC, then I can do that also. Using CFARGUMENT gives you no control what so ever on how you want to deal with the error from within the component. Once again, I see dealing with the error from within the CFC essential. Take for example, calling the CFC from flash. Wouldnt it be easier to handle the exeptions from within the CFC and pass back to flash the error, rather than, as I would imagine would happen, the code would error and flash would die. Yes I know you can see all this information from within the netDebug pannel, but once the application is live, and it errors, what can you do? For me, pesonally, I feel that CFARGUMENT, as a data validation tool need to have some sort of capcity to let the developer handle the errors produced by bad data, rather than just displaying the CF error template. Steve Onnis -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Geoff Bowers Sent: Sunday, March 02, 2003 5:37 PM To: CFAussie Mailing List Subject: [cfaussie] Re: CFC sprung doing naughty things Steve Onnis wrote: > It just makes more sense to handle this kind of thing in the cfc than > outside. Catch it once inside the cfc for all calls or write error handling > code every time you call the function in your code. Which would you prefer? > I would, and I guess most developers would choose the handle it once option. Not really. CFARGUMENT is performaing data type validation. The application making calls on the CFC should *always* be passing in the right variable types -- CFARGUMENT acts to protect the integrity of the function it finds itself in. If there is any chance that the call to the CFC will pass incorrect data types (eg, from some sort of user input) the input validation should be performed upstream -- ie. not in the component. The component should not have to worry about anything except itself. For example, trapping a database execution error within the function itself is appropriate -- the component should know how to communicate with the database if that is its job -- but it should not have to contend with incorrect data-types other than to refuse to cooperate ;) In any event, once you have trapped the error in your CF_ARGUMENT tag, what then? Don't you still have to return a result to the script calling your object, and presumably that script has to do something with the error? Also, CFARGUMENT populates the CFC metadata with information which is essential for the construction of self documentation and WSDL generation. I love CFARGUMENT. I don't think anyone should be giving it up in a hurry :) -- geoff http://www.daemon.com.au/ --- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] MX Downunder AsiaPac DevCon - http://mxdu.com/ --- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] MX Downunder AsiaPac DevCon - http://mxdu.com/
