I agree completely. -8<------ Well I think that the error trap you are looking for should be around the page/object that actually invokes the method. -8<------
Error codes / exceptions should be passed out of methods in the case of faulty data or problems executing. - It should not be that they are handled inside the method. If you wanted to catch the cfarguement exception and throw a new one with a custom error message, that would make a lot of sense as well, however. Mark -- [EMAIL PROTECTED] ICQ: 3094740 -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Geoff Bowers Sent: Sunday, 2 March 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/
