But the performance hit only comes when an actual error occurs. When no error occurs, the CFTRY/CFCATCH has very little overhead. As for the issue of StructKeyExists() over IsDefined(), I've advocated it in my presentations for a long time as it is logically more efficient. This may be a fallacy, but I believe it to be.
> 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:232358 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
