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.
 


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nando
Sent: Friday, June 23, 2006 5:18 PM
To: [email protected]
Subject: Re: [CFCDev] Need Help with Arguments in CFCs

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]





--


Aria Media Sagl
CP 234
6934 Bioggio
Switzerland
www.aria-media.com


----------------------------------------------------------
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