Purely theoretical thinking in the interest of conversation here but it seems to me that using cftry/cfcatch unnecessarily is a waste of the ever so precious overhead space. I call it theoretical thinking because I haven't really dug into the inner-workings of cftry/cfcatch to see what it actually does. I haven't done that because my use of it is very minimal and when/if I DO have to use it... I have to use it and it doesn't really matter how it works.
I wouldn't think that it was TOO much overhead just by thinking about what it's doing though. CF could display the error on the page or store that error information in a structure for you to do what you want with. But, again just logically thinking here, if an error DOES happen in a cftry/cfcatch block, that seems like it would be the only time (other than slightly more code) that any overhead concerns would pop up. I, of course, could be way off and CF may be attempting to compile the entire block looking for errors, then truly compiling it if there arent any errors. Like I said, I don't really know what it's doing but either way seems like a potential for (usually) unnecessary overhead. I'll admit, I used to use it quite often but I hardly ever use it now but when I do, it's never to catch an error that could have been completely avoided by something as simple as a cfparam. As for the example you used, I'd most likely try something like... <cfparam name="id" default="0" /> <cfif isnumeric(val(id))> ID was given, is numeric, and is not 0 <cfelse> Id was not given or wasn't numeric and therefore is 0 </cfif> The method that ID is being passed to the page could of course change that. I only used isnumeric() around it because apparently very large numbers or strings will cause val() to fail (I was just recently told that but haven't tried it out yet) Over the years, my use of isdefined() has gotten less and less... almost to the point of not using it at all. I've gotten into the habit of creating cfparams for almost everything that will be 'tested' (so to speak) in the way you've laid out. That's just the way I do things though. Taking a step back and looking at what cftry/cfcatch APPEARS to be doing just makes me think that it's more overhead than is usually needed. ..:.:.:.:.:.:.:.:.:.:.:.:. Bobby Hartsfield http://acoderslife.com -----Original Message----- From: Michael Dinowitz [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 15, 2006 10:38 AM To: CF-Talk Subject: Try/Catch vs. direct error handling This is a question of best practices and why. When I know there's a chance of a specific error, I tend to code specifically to handle it. Others code generally using try/catch. Which is seen as best in other languages and why? I doubt there's any real performance issue between them, so it's a question of industry standard and style. For example, if I know an ID is needed on a page and it has to be a numeric I'd do: <CFIF Not IsDefined('ID')> An ID is needed <CFELSEIF Not IsNumeric(ID)> The passed ID needs to be numeric </CFIF> Others do: <CFTRY> <cfparam name="ID" type="numeric"> <CFCATCH> You must pass a numeric ID </CFCATCH> </CFTRY> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Message: http://www.houseoffusion.com/lists.cfm/link=i:4:232354 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
