I just wanted to step in and let you know that I appreciate your
feedback and it is definately good to see two approaches and the
reasons for each. I was away for the weekend, but I have read through
the follow up threads and am learning from them.

Thanks everyone!

-Aaron

On 6/24/06, Nando <[EMAIL PROTECTED]> wrote:

 Jason, interesting reply ...

 I guess my point is this - if Aaron's experience is that during development
his code keeps failing on a "The argument xxxx passed to function xxxx is
not of type xxxx." error, then my sense is that this is something that
should be handled as part of normal application flow. Seems as tho' it's
very possible that in the case he's outlined, a non-numeric value would get
passed into that method.

 So it doesn't sound like he's running into "exceptions", as i would use the
term, if it happens so often. It sounds more like normal, "not preferred,
but it can happen sometimes" application flow. Using strong typing at those
points sets you up to use error handling for application flow.

 Now, what this implies is that you need an individual try catch block
around each piece of code that calls this particular method in your app that
gracefully handles the error, redirecting application flow.

 Is that properly encapsulated? Is it easy to understand when you come back
to it? Not to me. Sure, you can place strong typing on your argument, cause
the application to fail and make a very valid point that it's an exception
because the method required a numeric ... but in my opinion, the method
isn't "doing one thing and doing it well" in that case.

 Now, if you understand the implications of strongly typing your arguments
in a loosely typed language and choose to take that route for a particular,
well thought out reason, fine. But i think that implications here are easily
missed in the beginning for people new to using an OO approach in CF.

 I'd rather just use conditionals in such a place. My preference.
 I find it simpler to use an if IsNumeric() on the incoming value inside the
method to redirect the flow of the application than use error handling
outside the method at each point in the application where i call it for that
purpose. And i don't think it's extra overhead, as you seemed to imply (but
of course i might be wrong!). Strongly typing the argument will do the same
IsNumeric() check under the covers.

 But hey, if you showed me an application that used try/catch extensively
for that kind of thing, i'd study it carefully to see how you managed it and
i'm sure i'd learn something very useful! As i understand it, ColdSpring
uses a similar approach on startup, throwing and catching a series of errors
intentionally as part of normal application flow, for a very good reason.

 As for the Flex compatibility issue, of course we shouldn't jump to the
conclusion that every argument and returntype needs to be strongly typed in
our applications. I don't understand the whole thing yet, i've only got bits
and pieces so far. But in any case, Flex compatibility would only come into
play for objects you'd want to share across platforms. And from what i've
seen, that's a minor issue compared to all the other stuff we're going to
need to learn to get a decent Flex front end working. The Flex Builder GUI
makes it look deceptively easy, doesn't it!


----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to 
[email protected] with the words 'unsubscribe cfcdev' as the subject of the 
email.

CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting 
(www.cfxhosting.com).

An archive of the CFCDev list is available at 
www.mail-archive.com/[email protected]


Reply via email to