"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.
The point of CFARGUMENT is to protect your method. CFC's are designed to be black-boxen that can potentially work in other environments. When you are developing against a CFC it is beneficial for it to throw an error if you pass in the wrong data-type.
"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.
For what it's worth -- if it is a data type error you are receiving in this instance I still think that the error should be handled *outside* of the CFC. Clearly we don't see eye to eye on this one :)
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?
I wouldn't expect the Flash client to be passing invalid data-types. If it is a different type of error -- eg. database failure, whatever -- then perhaps the CFC should trap that error and return an appropriate response.
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.
Unless the CFC is being called directly with a URL then an app shouldn't be passing invalid data-types to a CFC. CFARGUMENT is there to ensure that the method never runs with invalid datatypes -- and provides default values, metadata, etc. It's really just an enhanced version of CFPARAM -- I'm still not sure why you feel it needs to do more than what it does.
-- 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/
