Hmmm. So if you'd be calling setDateOfBirth from outside the encapsulated boundary of the cfc (i'm not in this specific case but i'm lookin' for an education here), then the error is handled outside the cfc, which seems "irresponsible" to me. My "sense" of type validation in OO is that the object asking for validation should be able to handle it and return something useful, rather than toss a "Hey, it's not my problem" error out of the object boundary. That could wrong tho', I only have experience in CF so far.
I could be running across an implementation limitation of CF here as well. If so, then my workarounds are fine, (forget about type validation at the setter, use argument ... type="string" for all incoming data that a user or my logical error could botch *typewise*, and validate in a separate method - or within the setter itself). But if one of the primary arguments for using getters and setters is type validation, then i'd like to explore all the ramifications and come up with a solid approach. So far, i can't see how to make use of type validation in the argument tag in a clean way. :) nando -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Qasim Rasheed Sent: Thursday, August 12, 2004 3:24 PM To: [EMAIL PROTECTED] Subject: Re: [CFCDev] type validation / try catch blocks How about something like this when calling your function <cftry> <cfoutput> #setDateOfBirth('qasim')# </cfoutput> <cfcatch type="coldfusion.runtime.UDFMethod$InvalidArgumentTypeException"> <cfdump var="#cfcatch#"> </cfcatch> </cftry> On Thu, 12 Aug 2004 04:24:39 +0200, Nando <[EMAIL PROTECTED]> wrote: > One of the reasons i've heard put forth to justify using getters and setters > in an object is type validation. So for instance, let's say we've got a > setter for dateOfBirth and we type the argument to be "date" so that only > valid dates can be passed into the setter. > > <cffunction name="setDateOfBirth" access="private" returntype="VOID" > output="false"> > <cfargument name="dateOfBirth" type="date" required="true" /> > <cfset variables.instance.dateOfBirth = arguments.dateOfBirth /> > </cffunction> > > So far, so good. > > Now what would be best practice to handle the case when the incoming > argument isn't a valid date? To those in the know, excuse my trial and error > here, but i've not attempted anything in this direction. > > Attempt 1: > > <cffunction name="setDateOfBirth" access="private" returntype="VOID" > output="false"> > <cftry> > <cfargument name="dateOfBirth" type="date" required="true" /> > <cfset variables.instance.dateOfBirth = arguments.dateOfBirth /> > <cfcatch type="Any"> > <cfset variables.invalidFields = > listAppend(variables.invalidFields,"dateOfBirth") /> > </cfcatch> > </cftry> > </cffunction> > > Result - can't instantiate the object because of the <cftry> tag at the top > of the function - "Context validation error for tag cfargument. The tag > must be nested inside a CFFUNCTION tag." > > Attempt 2: > > <cftry> > <cffunction name="setDateOfBirth" access="private" returntype="VOID" > output="false"> > <cfargument name="dateOfBirth" type="date" required="true" /> > <cfset variables.instance.dateOfBirth = arguments.dateOfBirth /> > </cffunction> > <cfcatch type="Any"> > <cfset variables.invalidFields = > listAppend(variables.invalidFields,"dateOfBirth") /> > </cfcatch> > </cftry> > > Result - the try - catch block is ignored, the error isn't handled, and we > get an error screen announcing that "The argument DATEOFBIRTH passed to > function setDateOfBirth() is not of type date." > > Anyone have a suggestion how to handle type validation situations like this > seamlessly? My workaround is just to set the argument type to string, let > the invalid date in, and then deal with it in the validate method. > > Thanks, > Nando > > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email > to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' > in the message of the email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported > by Mindtool, Corporation (www.mindtool.com). > > An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED] > ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED] ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
