Then it is appropriate to use transaction processing and try/catch logic. You're dealing with more complex objects at this point already, dealing with the network and another server, this way even if you lose the network in the middle of running a proc or something it will roll back.
> -----Original Message----- > From: John C. Bland II [mailto:[EMAIL PROTECTED] > Sent: Wednesday, February 15, 2006 1:10 PM > To: CF-Talk > Subject: Re: Try/Catch vs. direct error handling > > So, in the case of a simple query what happens if your > datasource can't connect? (db down, etc) How do you handle > this error with an open cfquery? > onError in App.cfc? > > Just curious... > > On 2/15/06, Dave Carabetta <[EMAIL PROTECTED]> wrote: > > > > On 2/15/06, Michael Dinowitz <[EMAIL PROTECTED]> wrote: > > > 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> > > > > Actually, there is a performance difference between them in theory. > > try/catch introduces more overhead into the performance due to its > > need to run, evaluate, and then test the various catch > conditions for > > a best match. With the isDefined(), it either exists or it doesn't. > > Very simple and "brute force." Here are my two rules that I would > > submit as best practices: > > > > 1) In CFMX 6 and 7, every internal scope is a struct, and, as such, > > the struct-related functions have been heavily optimized. (I think > > there were some exceptions for scopes like "cookie" in previous > > versions.) Therefore, I almost never use isDefined() anymore, for > > reasons that have been documented both here and on various > blogs. My > > team's standards dictate that structKeyExists() be used > around checks > > for all variables: > > > > <cfif structKeyExists(variables, "id")> ... > > </cfif> > > > > <cfif structKeyExists(url, "id")> > > ... > > </cfif> > > > > The only time I can think of where I use isDefined() is in > something > > like an error e-mail where I want to check if there was a > form scope > > in the request that failed so that I can dump it or skip it. > > isDefined() will go through every possible scope it can, > including the > > CGI scope to find the variable being checked. That puts a > > (comparatively) noticeable overhead on the request as opposed to > > targeting a specific scope or scopes. I might be forgetting another > > one-off example, but you'll find most of the time that isDefined() > > just isn't needed. > > > > 2) Put cftry/cfcatch around code snippets that rely on > non-ColdFusion > > technologies, and around snippets of code that can > gracefully handle > > an exception. I don't put it around each and every query because I > > know that if a very basic query if failing, then I have bigger > > problems that a try/catch isn't going to solve. However, we > interface > > with a lot of non-CF technologies at my company (i.e., > Python external > > methods, web services, etc.), and I don't necessarily have control > > over their uptime or availability (for example). Therefore, > I need to > > be able to display a "system is down" message and/or send > an e-mail to > > myself as an alert. Other examples include POP and FTP access. > > > > try/catch should be used only when necessary. As for the reply that > > noted he has a developer who puts try/catch around everything, > > education is the best remedy there. Have him research > try/catch both > > in LiveDocs and across the web to show why his approach isn't > > recommended. > > > > Regards, > > Dave. > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Message: http://www.houseoffusion.com/lists.cfm/link=i:4:232355 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=11502.10531.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
