If you want the object to be encapsulated I think it is probably best to have it throw the default "Hey that's not a date" exception.
Anything you do to try to make it more intelligent will probably mean that the object has to know something about the context in which the method was called, so increasing the coupling of the object with it's environment. The right approach is probably to wrap up the call to the setter in a try/catch block and deal with the error intelligently based on the context in which it was being called. If that doesn't sound appealing then it's probably worth using some sort of data validation object prior to passing the data to the setters. The validation object can return some generic information about why the data isn't valid without needing to know anything about the context. The code that calls the validator can decide what to do if the date isn't valid. On a related note, part of the issue here is that you don't have a way to pass any sort of null to a method, so you have to either pass a date, or have an exception raised. Often in other languages you have the option of passing the correct type, or a null. That gives you a simple way of knowing whether what was passed is supposed to be valid or not. Unfortunately in ColdFusion we don't have that facility, so we're stuck with one of three options: 1. Pass a value that is the correct type, but is somehow understood to be incorrect (Say 1/1/1970 as a date) 2. Pass a value that is the incorrect type and catch any errors. 3. Don't specify a type in the cfargument tag. Of the three, I prefer the second option, but I would much prefer an option to somehow tell the method that the value should be treated as null. I'm not too sure how exactly you would go about implementing that, but it would be a good addition IMO. my 2 cents Spike -------------------------------------------- Stephen Milligan Code poet for hire http://www.spike.org.uk Do you cfeclipse? http://cfeclipse.tigris.org >-----Original Message----- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of Nando >Sent: Thursday, August 12, 2004 6:41 AM >To: [EMAIL PROTECTED] >Subject: RE: [CFCDev] type validation / try catch blocks > >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] ---------------------------------------------------------- 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]
