In that same vein (storing error in struct), isn't it conceivable the error stored in the cfcatch struct is going to be created whether you catch it or not? Obviously preventing the error is the best way but in the case of a cfquery gone wrong aren't you simply taking a struct that will automatically be created and literally catching it instead of allowing it to show on the page? If you look at the arguments passed to onError in App.cfc you will see CF pretty much spits out the struct (or just the info) as the error.
If all of this is true, there is no extra overhead since it is going to happen anyway. Going back to Mike's original post it would be extra to allow an error you know you can prevent. Why put your hand in a rabid dogs mouth if it is the last hand you have and your job requires at least one hand? It just doesn't make since, unless you want to collect disability. :-) ^ = my opinions On 2/15/06, Bobby Hartsfield <[EMAIL PROTECTED]> wrote: > > 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 aren't > 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:232362 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
