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!
Jason Daiger wrote:
Nando,
"Error handling should be reserved for
exceptional situations" -
I have heard Hal say this and I do not argee. If a method calls for a
numeric and it's sent a string is that exceptional? No but it's an
error that must be handled. What makes one error more exceptional than
another? Well it depends is the real answer. Error handling varies
based on the severity of the error and what makes one error more
'exceptional' than other is really an implementation issue. Is a db
query time-out error or a CF server crash more exceptional than a type
mismatch? They are more severe but both can cause the resulting page
request to fail. So for me any error that caused the request to
fail has my full attention. To raise an exception or pre-test
variables are valid implementation approachs. Since each error
situation is different there really is not one magic error handling
approach IMHO.
There is a school of thought,
one taught in many level Computer Science courses, that methods (and
functions) should use pre and post conditions. i.e. you give me X and I
guarentee to give you Y. E.g. isPrime(integer) : If you give me a
integer, I'll tell you whether it's prime or not. If you send
isPrime a string then it's free to 'throw-up' any way it wants. Having
the function check on each call when it could let the argument perform
validation is overkill in my opinion even for a loosely typed language
such as CF. CF's natural behavior of including one file after another
fits very nicely into this model. <cfincluded>
file displayMe.cfm requires X,Y & Z to be declared. If they are
not well file displayMe.cfm is allowed to bomb out. If anyone wants to
<cfinclude> displayMe.cfm they can as long as the meet the
precondition of providing X,Y & Z.
Now regarding CFC's, CF's hybrid
approach (ie. limited type checking) provides some built in type
checking, albeit at runtime, but why not leverage that feature in the
same manner you are leveraging the lack of type checking. Also, from
what I have read and researched, it sounds like using Duck Typing won't
work if you want to 'bolt-on' a Flex front end. So IMHO this means
developers should have a good long range picture for the future of the
application before taking the DuckTyping approach.
-Jason
P.S. BTW, I'm not against Duck
Typing in any way. It's a valuable tool to have in your development
toolbox. I think we should take full advantage of what the language
offers and Duck Typing is certainly one of those nice offerings.
Type checking ... I'm with Hal on this one. See his newsletters on the
issue at halhelms.com if you haven't already.
If you're going to do type checking in a situation where you don't have
absolute control over the type, then you need a mechanism to deal with
situations where the type might be incorrect - probably an error
handling routine at the point where you call the method (the one with
an argument that is strongly typed).
Now, if it's possible that the type could be incorrect in normal
application flow, then error handling is most likely the wrong
approach. Error handling should be reserved for exceptional situations.
Then you need some sort of filtering code deciding "well, if it's
numeric, then call the method that requires a numeric argument. If it's
not, then do something else."
If you open up your argument to "any", then you can do that checking
within the method. Which might make more sense. Why delegate part of a
method's or an object's responsibility to another bit of code when
probably the method should be able to deal with the matter itself?
I think sometimes we assume that typing an argument is the same as
checking that an argument meets our criteria. It isn't. Typing an
argument throws a runtime error in ColdFusion. It's for exceptional
situations. Again, if what you are trying to achieve is to check an
argument to see if it matches your criteria, you probably should use
IsNumeric() either before you call the method or after so you have a
mechanism to deal with it.
I say "probably" because i think that using error handling for normal
application flow is probably bad practice.
Now, in the case you use IsNumeric() for instance before you call the
method to handle normal application flow, what good is it to type the
method as a numeric? And if you use type="any" and check the argument
to see if it's numeric after it's passed in, well, you're not typing
the argument as numeric. (So what good is it?!)
In my opinion, if a strongly typed method "blows up" during
development, it's probably not an exceptional case that should trigger
an error, like your database server dying or CF heading into a reboot.
And ... even if it is an exceptional case, either the error is going to
say "such and such argument is not of the correct type" or it going to
say "arguments.suchAndSuch is not numeric" when your query is expecting
a numeric argument.
So all that said, what good is typing in ColdFusion? Since it's
compiled at runtime, if something goes wrong, either you get a runtime
error if it's strongly typed or you get a runtime error if it isn't ...
Unless you use code like IsNumeric() to establish application flow for
unusual but anticipated cases, and then typing isn't really needed, or
can't be used.
Now i'm not saying that strongly typing an argument is never useful.
But i do feel that it's usefulness in CF is much more rare than in a
strongly typed, pre-compiled language like Java where your code won't
compile if you've made a mistake and tried to pass a variable typed as
a string into an argument that accepts only numerics.
But you can't do that in ColdFusion, because a) you can't strongly type
a variable and b) it's compiled at runtime.
Aaron Roberson wrote:
It seems that every time I create a cfc with arguments
other than
string that I get a message like "The argument xxxx passed to function
xxxx is not of type xxxx."
This happens even when the argument is optional, and I have default
values of 0 or "". Right now it is happening when I don't pass an
argument to my cfc even though the argument is optional and the
default value is 0 (it's numeric).
Any suggestions?
Thanks,
Aaron
P.S. I did a search first, so if this is something that comes up often
and has been answered elsewhere, please forgive me - I tried.
----------------------------------------------------------
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]
----------------------------------------------------------
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]
----------------------------------------------------------
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]
|
