That being the case.. I suppose you could invoke a ERROR object, that has your default error code display / prevention handling there?
"Elliot Russo" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > Hi, > > I might be off track here - but I agree with steve. As a webservice you > can't and don't want to implement the same vaidation code all over the shop! > Even if it isn't 'pure' OO, which we could debate. There are validations > other than simple datatypes anyway, bounds, patterns etc. and its nice to > handle it there. by all means do it in your calling code too, to save even > making the cfc call if you want. It really is more encapsulated you could > say because you have to know even less about calling it right, and when you > call it wrong it tells you why. > > My 1 cent worth > > Elliot > > "Mark M" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > > > ---8<------ > > 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. > > ---8<------ > > > > I would say in this example the UserID should be handled in some way to > > give the method a value it can handle. Make it zero if you will. This > > should be handled outside the method. The method is not an all powerful > > being that handles everything. It is only there to do one thing, and one > > thing only. > > > > ---8<------ > > 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? > > ---8<------ > > > > If that was the case - the person invoking the webservice DESERVES to > > get an error message. > > > > If I tell you to give me a number, and you give me anything but, what do > > you EXPECT to happen? :oP > > > > It's like saying 'hey, if you jump off that rooftop, you are going to > > get hurt', and then someone jumps off the rooftop and break their leg, > > they are wondering why they are lying there in agony. > > > > If I tell you to pass me a number, pass me a number damnit! :o) > > > > Mark > > -- > > [EMAIL PROTECTED] > > ICQ: 3094740 > > > > > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Steve > > Onnis > > Sent: Monday, 3 March 2003 1:12 AM > > To: CFAussie Mailing List > > Subject: [cfaussie] Re: CFC sprung doing naughty things > > > > 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/ > > > > > > > > > > --- 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/
