Although, as Spike mentioned earlier, keep in mind that in those typed
languages you're able to pass null as an acceptable argument value for
any data type. CF's lack of null has given me some run-time problems
when working with CFCs, specifically when I try passing an empty
string to a setter that expects a date or numeric cfargument. I've
worked around this the hard way... set the cfargument type attribute
to "any" and then do a quick:
<cfif not isDate(arguments.whatever)>
<cfthrow type="InvalidArgumentTypeException" />
</cfif>
It's a pain, but it gets the job done (and effectively emulates a
strongly typed language... at least as far as method calls are
concerned).
On Thu, 12 Aug 2004 15:43:09 -0400, Roland Collins <[EMAIL PROTECTED]> wrote:
> I agree with Barney here.
>
> Think about the way a typed language would handle it. In Java/C++/.NET,
> etc., if you declare a parameter as a certain type and pass it a value of an
> different data type at runtime. If you want to allow for this possibility,
> you wrap the call to the method containing said parameter in some manner of
> error handling mechanism. The "invalid parameter type" error happens on the
> call to the method, not from within the method itself.
>
> If for some reason you want to do the type-checking within the method
> itself, you are forced to use some generic data type, such as Object, in
> most modern typed languages. I, for one, do not like this approach at all,
> as it limits the ability of many languages to do compile-time type checking.
> Even though CF does not do this, I find sticking to the same paradigms that
> I'm used to in stricter languages greatly eases my pain.
>
> ..02,
> Roland
>
>
>
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
> Of Barney Boisvert
> Sent: Thursday, August 12, 2004 12:16 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [CFCDev] type validation / try catch blocks
>
> There's not reason you have to abort after the first error. IN your
> procesing script, fill in the fields, catching any errors that arise,
> and recording them to some temporary data structure. When you're
> finished, then you can list all the errors and regenerate the form.
>
> The business object shouldn't attempt to deal with an invalid
> parameter type, because it doesn't know anything about where that
> parameter came from, and that's essential for knowing how to respond
> to the exception. So the BO is handling the mistyped data (saying
> "hell no, give me the right thing"), but it's not trying to convert
> that error into something meaningful to the client (which is a UI
> issue).
>
> Just to through another idea out there, have generic setters that
> don't check type, or even a single set method that takes both a field
> and a value. Then have a validate method that rolls typechecking and
> semantic validation into a single method for the whole object. It
> should generate a collection of validation errors (missing password,
> birth date isn't a valid date, email is invalid, etc.) which can then
> be processed however. This is the approach that I've generally taken,
> and it seems to work quite well.
>
> cheers,
> barneyb
>
> On Thu, 12 Aug 2004 17:51:14 +0200, Nando <[EMAIL PROTECTED]> wrote:
> > 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. :)
> --
> Barney Boisvert
> [EMAIL PROTECTED]
> 360.319.6145
> http://www.barneyb.com
> ----------------------------------------------------------
> 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]
