New Feature - CFRETRY

November 27, 2012 · By Gert Franz · 11 Comments

Sometimes receiving an error is an indication, that something isn't in the stat you expect it to be. So we have introduced the new tag CFRETRY. It comes with a set of jump statements which will be introduced in Railo 4.1 and which we will be blogging about soon. So let's start with CFRETRY.

CFRETRY will do exactly what the name states. It will try to reexecute the code framed by the CFTRY tag it is used in. So consider the following code:

<cftry>
   <cffile action="copy" source="C:\test.xml" destination="d:\susi\test.xml">
   <cfcatch>
      <cfif not directoryExists("d:\susi")>
         <cfdirectory action="create" directory="d:\susi">
         <cfretry>
      </cfif>
   </cfcatch>
</cftry>

Next to the tag CFRETRY there also exists the statement retry which you can use inside CFSCRIPT as well. The use cases for tag CFRETRY are numerous. It is another tool you can use for structuring your application and improve the code quality. Comments are as usual warmly welcome.

View count: 31616

Tags: CFML · Features · New release · Railo 4.1

11 responses so far ↓

1 Michael Zock // Nov 27, 2012 at 4:40 AM

In cases like FTP transfers over a flaky connection (e.g., if the other side is using a cellular modem because it's so far out in the boondocks) this could definitely be a useful shortcut.
2 Peter Pham // Nov 27, 2012 at 10:44 AM

Awesome. But is it possible to run into an endless loop? Or is there a feature to throw out error after so many attempts?
3 spills // Nov 27, 2012 at 4:37 PM

Looks good, but an additional parameter for timeout or number of retries seems needed?
4 Gert Franz // Nov 27, 2012 at 4:58 PM

I think there is a point to it. I will raise this internally so that we can adapt it accordingly. I think something like cfretry times="2" should do. Might look different though.

Gert
5 Michael Zock // Nov 27, 2012 at 5:19 PM

Normally I'd just wrap a cfif tag around it, but a built-in counter or a condition parameter doesn't sound bad either.
6 Simon Wright // Dec 5, 2012 at 2:10 AM

And by default it probably should be one retry. If the same error isn't fixed as a result of running the cfcatch code there's no reason to think it'd work the next time.

When the number of retries fails, I see two possible options: either the retry becomes inert and execution continues as normal... or we specify a throw parameter and allow a different catch block to handle that scenario.

I think the former is the cleaner and more flexible option.
7 Tom // Jan 11, 2013 at 10:21 PM

I could see this being useful in the scenario where your are performing file operations that fail because of a file lock. You could set this with perhaps parameters for time, noOfRetries and intervalBetweenTries.
8 Offner Michael // Feb 15, 2013 at 11:05 AM

The risk of endless loop is part of many constructs and in the responsibility of the programmer from my point of view, if we add a fail safe like this, we need to add this also for example to cfwhile/while statements, cfinclude, any function call, ...
-1 from me
9 Simon Wright // Feb 24, 2013 at 1:37 AM

Michael: I would agree with you if this was C++ or Java, but CFML is a language for which convenience is king, and where common scenarios are given terse shortcuts.
10 Michael Zock // Feb 24, 2013 at 11:00 AM

Michael: What about a condition parameter?

That way, the developer would be responsible for providing a boolean and you could re-use code from the "while" loop. More versatile than a plain counter and the resulting overhead should still be manageable.
11 Michael Offner // Feb 25, 2013 at 8:53 AM

@Simon
my point is about consistency.
IF we do so, we have to do the same for other constructs as well.
<cfwhile condition="#c#" times="100">
while(c;100)
...

@Michael
if(myCondition)retry;
this would be only a convinience paramter like <cfdump abort>, i'm not a big fan to overload tags,functions statements with attributes,arguments parameters not directly related to the functionality. so i would prefer a "times" parameter, then this actually reduce the work for the programmer, a "condition" parameter not.

i will start a thread about this in the mailing list

Default