RE: [CFCDev] Need Help with Arguments in CFCs

[Jason Daiger]

Nando,   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 Possibly but I prefer the type safety approach (I'm using 'type safety' loosely mind you).  I flipped all my params to fully typed (e.g. com.attendeeinteractive.user) instead of (user or any) b/c I don't want just any old value passed in.  It's a personal choice I've made that says, run-time type mismatch errors are ok by me.  As an FYI, since I'm using a factory approach to get objects or a service approach to save or do things I can unit test each piece.  Assuming my unit tests pass I'm safe to assume I won't hit that type of error at runtime unless I give something invalid input. E.g. user.setBirthday('2006-0-5b').  That's a validation question which is either handled by the object or an external validation system depending on the needs. (I believe we discussed that issue a week or so ago)    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 I'm not saying you have to use the try/catch everywhere.  I'm saying if you unit test the method w/ the valid preconditions and it passes the tests, then plug forward.  If someone uses the class and calls the method with invalid data then it's free to throw either a run-time error or an user caught exception and thus disrupt the application flow.  I tend to ask myself "who problem is it?" when working out error handling.  If it's a simple method (such as isPrime ) should it really worry about error handling?  In some cases the answer is yes and in some no but in both the pre/post conditions are defined. In my example of 'isPrime' I would say no try/catch is needed.  For a method such as a saveAUser then yes it must trap and handle errors.   I look at the context of a method, how it might get used and by whom (other program functions) to determine the best approach.  I have not found 1 unified approach to error handling and therefore use multiple approaches, including testing w/ isNumeric to ensure it's a number when I need to guarantee its a number.   -Jason           From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nando Sent: Saturday, June 24, 2006 9:33 AM To: CFCDev@cfczone.org Subject: Re: [CFCDev] Need Help with Arguments in CFCs 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.   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Nando Sent: Friday, June 23, 2006 5:18 PM To: CFCDev@cfczone.org 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 cfcdev@cfczone.org 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/cfcdev@cfczone.org ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org