Geoff "The data validation rule applied by CFARGUMENT is there to make sure that the method can do its job correctly"
I totally agree with you. But the reason I bring this up is that there is no way to handle the exeption from within the CFC, rather you have to do more code in your cfml templates to handle the error. I actually wrote my own cf_argument tg last night that actually ckecks the validation, and returns the errors in a catchArg structure. This was if there are errors, I can handle them inside the cfc and not have to worry about trying to catch them when I call my functions in my templates. 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. Steve Onnis -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Geoff Bowers Sent: Sunday, March 02, 2003 12:09 PM To: CFAussie Mailing List Subject: [cfaussie] Re: CFC sprung doing naughty things Well I think that the error trap you are looking for should be around the page/object that actually invokes the method. The data validation rule applied by CFARGUMENT is there to make sure that the method can do its job correctly -- if code upstream is not passing in the appropriate data-types it doesn't seem like an error the method itself should have to manage. -- geoff http://www.daemon.com.au/ Steve Onnis wrote: > Hey back again, at 3am:P > > Just looking for some pointers regarding catching errors produced BY the > CFC. > > Just say for example we have this simple CFC as outlined below. > > *<cffunction name="getUser" hint="Get the user" returntype="query"> > <!--- User ID is required ---> > <cfargument name="UserID" required="Yes" type="numeric"> > <!--- Query database ---> > <cfquery datasource="#request.thisApplication.datasource#" > name="getAllowed"> > SELECT * > FROM Users > WHERE UserID = #arguments.UserID# > </cfquery> > <!--- Return result ---> > <cfreturn getUser> > </cffunction>* > > Now...........this is all good and well and wont error unless no userid > has been passed in. Now the purpose of having a CFC is to encapsulate > your code logic right?? So I ask the question, is there a way to catch > the error that the CFC would make if the required arguments were not > passed in? > > There are many ways I could get around this. For example, I could pull > the whole CFARGUMENT part out of the CFC and test for the arguments > myself, see whats missing and then return the error message. But then > whats the point of having CFARGUMENT available then? > > Wouldnt it be better to be able to put a CFTRY around the CFARGUMENT and > everything else inside the CFC? > > Like this... > > *<cffunction name="getUser" hint="Get the user" returntype="query"> > <cftry> > <!--- User ID is required ---> > <cfargument name="UserID" required="Yes" type="numeric"> > <!--- Query database ---> > <cfquery datasource="#request.thisApplication.datasource#" > name="getAllowed"> > SELECT * > FROM Users > WHERE UserID = #arguments.UserID# > </cfquery> > <cfcatch> > <cfset getUser = QueryNew("UserID,UserName")> > </cfcatch> > </cftry> > <!--- Return result --->* > * <cfreturn getUser> > </cffunction>* > > This to me is encapsulating code, where by all processing of code is > handled in the one spot, in the CFC. Not to mention the less code you > will have to write when calling your components, not only in CF, but in > flash also. > > To be able to handle all your exeptions from within your CFC, to me, > seems way to logical to not be able to do it. > > So this issue I am adding to my CFC wishlist. > > Regards > > Steve Onnis > Domain Concept Designs > +61 422 337 685 > +61 3 9431 4249 > > *http://www.domainconceptdesigns.com* <http://www.domainconceptdesigns.com/> > [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>* > *http://www.cfcentral.com.au > <http://www.cfcentral.com.au/>[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>* > > ** > > ** > > ("If you think it can't be done, you haven't asked me!") - Steve Onnis > > --- 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/
