Steve, At TQ we've gone down this path of thinking, and in truth it comes back to one principal thing:
Keep your presentation code / layer out of the CFC logic. Using the CFTRY/CATCH system in the PageContext layer, is much more efficient in re-use of the CFC and well fluffy look / feel control as each site will be unique. If you need to invoke the loggin method (which we do), its then a matter of yourobject.logThisError(errorStruct); Usually most "pages" have most of their CF logic at the very top, so you can wrap them quite easily in CFTRYs Scott "Steve Onnis" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > 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/
