cftry/cfcatch With Database Response
I did a search on cftry and cfcatch, and somehow I missed the logic behind some of the pages describing it. So I’m writing up a quick example in hopes that maybe my demo will light someone’s bulb more than the rest.
I’m writing a backend for a system whose frontend is Flex. The flex expects a response of 100 for a successful process and 101 for an error, plus a couple detailed responses for debugging purposes. This is returned in XML format which the Flex application is expecting, but I won’t bother including the formatting in the code since it’s all too simple to output XML.
In this case, the Flex form is submitting some values for a user to change some profile settings.
<cftry>
<cfupdate datasource="testdb" tablename="users">
<cfset success="True">
<cfset status="100">
<cfset desc="Everything worked">
<cfcatch type = "Database">
<cfset success="False">
<cfset status="101">
<cfset desc=cfcatch.message>
</cfcatch>
</cftry>
There are a number of <cfcatch> types, most of which I have not yet had opportunity to use. But it is worth noting you can “try” a number of operations together and also “catch” multiple operations within the same <cftry> tag. The “type” attribute tells ColdFusion what it’s trying to catch. This includes types such as “MissingInclude” or “application” to correspond to missing include file errors or general application errors.
In PHP it was a different process as a mysql_query tag could give a Boolean response to indicate it worked. In ColdFusion this might be possible as well but I could never manage to get it to. So if you want any sort of success/fail response from a cfupdate, cfinsert or cfquery (or any other function for that matter), the above is what you’ll need to set up.
try/catch is useful for allowing your code to continue execution if there is an error. Be aware though that if code within TRY does generate an error, it “hides” this error from your application-level error handling.
In the case of database requests, I’ve found that I prefer for my pages to fail entirely and allow the application to handle the error. This is because most of my work depends upon the database, and DB requests only fail when I code incorrectly.
I’ve customized my application error handler to send me a notification upon each error, which is immensely helpful. If I want to get a notification of a try/catch block fail, I have to explicitly write that code inside of the try/catch block.
Good call. The application we’re applying this to is fairly small so it wasn’t a big deal expicitly writing the code inside the block. On a larger codebase it would get a bit more tedious so I see what you mean. We did experience the “hidden error” but we had output the “cfcatch.message” to xml and brought in the actual message into Flex so it was a fairly simple process to display the message.
I see the existence of this small debate as a CF design flaw in the first place. There should always be a clear response when attempting or “trying” a getter or setter. If it works, take me somewhere… if it doesn’t work, take me somewhere else. Of course that destination needs to be stated, but there shouldn’t be “hidden” responses in the first place.