I know that could sound very right theroetically, but taking this case of an object that models a person as an example, you're filling in a form. You do your best but like all of us, you miss a few fields, 2 have wrongly typed data, etc.
Submit. The process hits the first argument tag with a mismatched type and throws an error. I, the programmer, handle it outside the object and give you a "Please correct ..." message. You correct the first mismatched type and Submit. Bam. The process hits the second argument tag with a mismatched type and throws another error and renders another "Please correct ..." message. You think "Idiot! Who built this thing!" and somewhat angrily correct the second error. Submit. Unknowingly, you forgot 2 required fields, and although the process now clears all the argument tags in the business object, my validation routine catches the 2 empty variables and returns you to the form with yet another message. Now you're really pissed. Obviously, that's not the way it should work. Even if you're handling validation in a separate object for instance, talking the "It's not the business object's responsiblity to handle wrongly typed data", the above scenario would still play out in the same way, one error at a time. Hence, it still seems "irresponsible" to me, and users would immediately pick it up. And so it seems to me that the object asking for validation should be able to handle all validation comprehensively. Hmmm? Or am i talking myself into a corner here? n. :) -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Brian Kotek Sent: Thursday, August 12, 2004 5:19 PM To: [EMAIL PROTECTED] Subject: RE: [CFCDev] type validation / try catch blocks Seems to me that it should be the responsibility of the calling code to handle the error, right? If you call a method on a CFC and pass in an invalid argument (or no argument at all), is that really the CFC's problem? I would say no. The CFC throws an error, and it's up to the caller to determine what to do. The alternative would be that the CFC decides for you what to do in the case of an error. Does it just return false? Does it return an empty string? What if it is a void function that has no return type, then what should it do? I'm not sure how the CFC could know what it is supposed to do. Throwing an error back at the caller seems to be the right thing to do. But of course (here comes the standard caveat of course! ;-) I could be totally wrong since I'm certainly no OO guru. Regards, Brian -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nando Sent: Thursday, August 12, 2004 10: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] ---------------------------------------------------------- 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]
