C#: try and retry

re: C#: try and retry

Ayende Rahien — Sat, 01 Oct 2005 18:20:11 GMT

One thing that worries it about having retry is that it's easy to get into infinite loop.
But that is minor, as your code showed.

What is interesting is /where/ does it restart? On the begin block or on the line that had the exception

re: C#: try and retry

abhinaba — Mon, 03 Oct 2005 07:47:42 GMT

It restarts at the begin block. So you need to ensure that re-execution of code in between the begin and the point where the exception got thrown does not have any side effect

re: C#: try and retry

Thong Nguyen — Mon, 03 Oct 2005 12:52:51 GMT

I've already created an Action.Retry function that supports retry count and timeouts.
It uses closures to allow you to naturally use any code you want in the retry.

object myObj = ...

Actions.Retry<object>(delegate
{
myObj.NetworkAccess();
}, TimeSpan.FromSeconds(10));

You can also specify which exceptions to catch and wait periods between retries....

A bit more powerful than the "retry" keyword though I can see the "retry" being of some use.

re: C#: try and retry

Ramsey — Tue, 04 Oct 2005 12:03:21 GMT

There were discussions on C# forums sometime back on including retry in the language. Don't know about the current status though

re: C#: try and retry

dhchait — Fri, 07 Oct 2005 18:57:38 GMT

I tend to use a pattern similar to:

foo() {

bool keepTrying = true;
while ( keepTrying ) {
try {
string filename = showDialogBox();
Stream stream = openstream(filename);
writestufftostream(stream);
stream.close();
keepTrying = false;
} catch (Exception ex) {
// prompt to retry fail etc.
keepTrying = messagebox("failed: " + ex.Message + " - keep trying?");
}
}
}

pseudo-code but you get the idea. a retry keyword would fit nicely into the above scheme, i tend to do this a lot - especially in gui apps where you show a dialog then try to use the input, and may need to go back and retry it if the input is bad....

re: C#: try and retry

mschaef — Tue, 08 Nov 2005 18:29:36 GMT

"What is interesting is /where/ does it restart? On the begin block or on the line that had the exception "

This is one of the more interesting parts of Common Lisp. It has exception handling that allows exceptions to be handled before the stack is unwound. It's also possible for code to establish named (and unnamed) restarts that allow exception handlers to restart the code in particular spots. If you were writing a function that threw a 'bad argument' exception, you might offer two restarts: one to retry the call with another argument and one to abort the call and assume a particular return value. It's key that all of this can be defined and overridden by the developer.

More information:

http://www.nhplace.com/kent/Papers/Condition-Handling-2001.html

re: C#: try and retry

David Totzke — Wed, 09 Nov 2005 02:51:16 GMT

This is crazy talk and just begging for trouble.

while (!Wrapper(downloadMgr)) ;

So somebody kicks out your network cable and the Wrapper function starts to return really fast because whatever it is calling will wise up to the fact that the network is _gone_ and there you are in a 100% CPU tight loop that you can't kill.

Been there, done that, bought the T-Shirt

re: C#: try and retry

abhinaba — Wed, 09 Nov 2005 08:32:23 GMT

David you are taking things too literally. No one is ever going to loop infinitely in a tight loop trying to do something on the network :)

This is just a example meaning that you put all the retyring logic in the wrapper function and call it eternally. So wrapper should have the logic of counting how many retries it made and fail when it goes above some value.

re: C#: try and retry

RichB — Thu, 15 Dec 2005 19:33:28 GMT

In the past I've done retries using C# anonymous delegates - ie the codeblock I want to retry is first wrapped in a closure which allows me to execute it numerous times. Having it inside a delegate means it suddenly has a common interface and so the retry code can be written just once for many different types of codeblocks.

To put another way, I've used the Command Pattern, but my Do() function has been simplified to just calling a delegate.

re: C#: try and retry

Hugh Gleaves — Sat, 17 Dec 2005 18:50:41 GMT

Hi

I do like this whole retry idea, and have posted about it on GotDotNet (though not without some heated debate!)

http://www.gotdotnet.com/Community/MessageBoard/Thread.aspx?id=352875&Page=1#353303

I have proposed to MS that they consider extending the syntax of 'try' to include an option expression:

try (expression)
{
code;
}
catch(Exception e)
{
handling;
}

This captures (I think) the key issues and implememnts them in the langauge:

1. A loop
2. A termination condition
3. Execution of the handler after all retries have failed.

I have also thought that this may be better, but this is just an idea:

try (retries,interval)
{
code;
}
catch (Exception e)
{
handler;
}

This is better, because it forces the coder to define a) the number or repetitions (before the handler finally runs) and b) a sleep interval to avoid tigh cpu loops (but they could put 0.

The idea here is to provide a construct

Both of these constructs can be expanded to a while loop etc, and would be automatically generated by the compiler, much as a C# iterator gets expanded.

re: C#: try and retry

David Betz — Wed, 11 Jan 2006 08:41:37 GMT

http://davidbetz.net/winfx/2006/01/constrainted-try-with-retry-mechanism.aspx

re: C#: try and retry

lesbian rape — Fri, 23 Jun 2006 10:38:13 GMT

Best of all people w can talk...

re: C#: try and retry

Michael Hübner — Fri, 23 Jun 2006 18:40:04 GMT

In good old Smalltalk, the search for an appropriate exception handler leaves the stack in its current state (same as in Common List), i.e. does not unwind the call stack.

This has the advantage, that in an exception handler (usually in the top handler) a debugger view can be opened, which allows you to inspect the life data which caused the exception, at the position in the code where the exception occured.
This safes you a lot of time when chasing errors.

re: C#: try and retry

David Walker — Tue, 05 Sep 2006 18:05:15 GMT

http://blogs.msdn.com/oldnewthing/archive/2005/11/07/489807.aspx

From Raymond Chen:

"I've seen this go wrong many times. So much so that my personal recommendation is simply never to retry automatically. If something fails, then report the failure. If the user wants to retry, let them be the ones to make that decision.

Here's how it goes wrong. This is a real example, but the names have been removed because I'm not trying to ridicule anybody; I want you to learn. There was a networking feature that implemented some type of distributed networking capability. It is the nature of networks to be unreliable, so the implementors of the functionality decided to retry ten times before finally giving up. The operation they were performing was implemented by another group, and that other group also decided to retry five times before giving up. That second group called a networking function with a timeout of thirty seconds. Meanwhile, the application that used this networking capability attempted the operation fifteen times.

Let's do some math. At the bottom was a timeout of thirty seconds. Five retries comes out to two and a half minutes. Ten retries from the next layer brings this to twenty-five minutes. Fifteen retries from the application layer takes us to over six hours. An operation that would normally have completed (with a failure code) in thirty seconds became, through the multiplicative effect of multiple layers of retrying, a six-hour marathon. And then you get a very angry call from one of your customers demanding that you deliver them a fix yesterday because this problem is taking down their entire sales force."

re: C#: try and retry

Steven Oliver — Sun, 29 Jul 2007 20:59:03 GMT

Thanks the ruby retry code. Exactly what I needed.

Ruby.NET

I know the answer (it's 42) — Thu, 22 Nov 2007 15:30:43 GMT

I had blogged earlier about Gardens Point Ruby.NET . After I read Don Box writing about it, I decided

re: C#: try and retry

mtsay — Tue, 21 Apr 2009 19:26:01 GMT

another ugly method to work around the issue using existing construct and no goto:

{

try

{

...

}

catch ( ... )

{

...

continue;

}

while(false);