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]
