ok take this for example
I have a CFC. This CFC required an argument called UserID. The UserID MUST be a Number. The UserID is passed in but is blank. What do you want to do? Display the CFML error template or handle the error from within the CFC in some way, for example returning nothing back to the caller. Unless you try and handle it in the code calling the CFC, there is no way of doing it. Lets say the above example was actually being used for a web service. If you were the one using this web service, would you want to be handling the catch code or would you prefer that if it errored, to return to you a specific error code or something to tell you that something has gone wrong? Steve -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Mark M Sent: Monday, March 03, 2003 1:00 AM To: CFAussie Mailing List Subject: [cfaussie] Re: CFC sprung doing naughty things Steve - I need to ask - In what instance would you have a CFC that requires a string to run... and you would pass in an array? Methods should do one thing and one thing only, by good software design standards. (Cohesion and Coupling... remember these things?) Making a method take multiple types goes against these basic principles. CFArguement is the ColdFusion way to ensure that types remain the way they should be. Unfortunately we can't compile our code and test it that way. I don't want someone passing in a number, when really what I want is an array. Its going to stuff my whole method. Presto. Cfarguement. Why would I use anything else? I hope this makes sense :o) Mark -- [EMAIL PROTECTED] ICQ: 3094740 -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Onnis Sent: Sunday, 2 March 2003 10:06 PM To: CFAussie Mailing List Subject: [cfaussie] Re: CFC sprung doing naughty things 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/ --- 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/
