C# keyword enhancement: try / catch / retry / finally

[Dave Sell]

Looking for feedback on this idea I had. I am mostly using C# so I am just thinking about this language but probably this is a .NET framework topic.

Over the years, I have had to implement a clunky-ugly second try catch inside of the catch block in order to perform a "retry" in case of an error.

Since I feel that it is not uncommon for us internet software engineers to need to "retry" an operation, should Microsoft include a new keyword, retry to the language?

I would imagine it would look something like this:

try
{
  // make a call, log the inputs
}
catch (Exception e)
{
  // oops, log the error
}
retry ()
{
  // since we pass in no value, retry this immediately, 
  // but only if we hit the previous catch
  // make the same call, log the inputs
}
catch (Exception e)
{
  // I think we still need a catch, log the error
}
retry (1000)
{
  // since we pass in a value, wait 1,000 ms and then try again, 
  // but only if we hit the previous catch
  // make the same call, log the inputs
}
catch (Exception e)
{
  // I think we still need a catch, log the error
}
finally
{
  // cleanup and log event
}

As you can see I am big on event logging lol. So the idea is, once you succeed in the try, or the first retry, you skip down to the finally. In the example above, the developer wants 2 retries after the first try. I believe you could have as many as you want, as per the discretion of the developer, during coding time, before compile-time.

I am posting this here because I have always gotten such awesome feedback from this community over the years.

P.S. I decided not to ask for a wait keyword, because I think it's more readable to pass in a value to the retry to signify a wait time. Why milliseconds? I dunno, I kinda like milliseconds.

Thanks,

Dave

[Sitten Spynne]

I like the idea, but there's already several idiosyncratic patterns for this kind of retry logic?

while (!success && !exitCondition) {
    try {
        ShakyAlgorithm();
        success = true;
    } catch (Exception) {
        // update exitCondition
    }
}

The team seems to resist new language features if there's a low-friction solution.

[Dave Sell]

Yes, as I originally stated. Also, your "frictionless" solution does not address waiting, and performing alternate retries that are designed to be polite. Your solution, in a cloud-based, high volume environment, is quite rude, and could kill a system that is simply experiencing momentary difficulty. Here is a more specific example than my original generic example. Notice the politeness factor:

try
{
  // send email to SMTP server 1
}
catch (Exception e)
{
  // log the error
}
retry (1000)
{
  // send again to same SMTP server 1 after waiting
  // log specific event
}
catch (Exception e)
{
  // log the error specific to retry
}
retry
{
  // send email to SMTP server 2
  // log specific event
}
catch (Exception e)
{
  // log the error specific to retry
}
finally
{
  // cleanup and log event
}