Proposal: retry try statements

[GeirGrusom]

Sometimes an exception has been thrown because of a temporary state, such as network error. In order to replay the try block in C# 6 you would implement a loop. This will cause the finally block to run for every retry which may be undesirable. You cannot jump from a catch to a try scope since the label is out of scope.

I propose that a standalone try; replays the try block. Alternatively, a new keyword retry could be used.

var resource = GetResource()
int retryCount = 0;
try
{
    targetInfo = await resource.GetNetworkUserInfo();
}
catch(TimeoutException) when (++retryCount <= 3)
{
    await Task.Delay(10000);
    try;
}
finally
{
    resource.Dispose();
}

The finally block is only executed once regardless of how many times the block was retried.

[Logerfo]

int retryCount = 0;
try
{
    targetInfo = await GetNetworkUserInfo();
}
catch(TimeoutException) when (++retryCount <= 3)
{
    await Task.Delay(10000);
    try
    {
        targetInfo = await GetNetworkUserInfo();
    }
    catch(Exception)
    {
        try; //which "try" block does this point to?
    }
}

[orthoxerox]

@Logerfo What loop does break; point to?

[Logerfo]

@orthoxerox unfortunately, c# break doesn't support argument like PHP does. We could have try labels, though:

int retryCount = 0;
try first
{
    targetInfo = await GetNetworkUserInfo();
}
catch(TimeoutException) when (++retryCount <= 3)
{
    await Task.Delay(10000);
    try second
    {
        targetInfo = await GetNetworkUserInfo();
    }
    catch(Exception)
    {
        try first;
    }
}

[GeraudFabien]

I don't understand why put the "when (++retryCount <= 3)" on the "catch" line. If you have many catch each catch must have the same condition otherwise it will be hard to understand the flow and debug (I thinks).

int retryCount = 0;
try when (++retryCount <= 3) // while
{
    if(retryCount == 0)
    {
        // first
        targetInfo = await GetNetworkUserInfo();
    } 
    else 
    {
        // second
        targetInfo = await GetNetworkUserInfo();
    }
}
catch(TimeoutException) // Maybe some other conditional https://github.com/dotnet/roslyn/issues/11889
{
    await Task.Delay(10000);
}
catch(TimeoutException) 
{
    // Some other thinks
}
catch(OtherException)
{
    // or "break try;" or "try;"
    break; 
}

[GeirGrusom]

@GeraudFabien

I don't understand why put the "when (++retryCount <= 3)" on the "catch" line.

Because that is what by C# supports at this point, and different exceptions may have different retry conditions.

Take this hypothetical, wrong and probably far-fetched example:

string connId = "db1";
int count = 0;

try
{
  db.ConnectionString = GetConnectionString(connId);
  await db.OpenAsync();
}
catch(TimeoutException) when (++count <= 3)
{
  try;
}
catch(BadCredentialsException) when (connId != "db2")
{
  connId = "db2";
  try;
}

@Logerfo

We could have try labels, though

We could, but I don't really think it's necessary. It should probably go in a different proposal as well.

[alrz]

You are coupling the actual procedure and retry logic. you probably should be using a separate method/type to handle that logic. However I can see this could be covered by modifying generators (#122)

[[Retry(3)]]
{
  DoSomething();
}

or something like that.

[GeirGrusom]

You are coupling the actual procedure and retry logic. you probably should be using a separate method/type to handle that logic.

You are making a sweeping comment on code structure that I don't think is really relevant here.

However I can see this could be covered by modifying generators

[[Retry(3)]]
{
  DoSomething();
}

You try to fit my simple example without giving any thought to the point that some exceptions are recoverable. I used TimeoutException as an example where it just waited for whatever to resolve itself. But it may be updating a database record, or doing anything else before retrying.

Also, this feature is fairly simple. It is no more complicated to implement than continue. Code generators are however are not simple to implement, and your example would introduce a lot of cognitive load.

[scottdorman]

I think I'd rather see this as a retry keyword.

In @Logerfo's example (shown below for reference)

int retryCount = 0;
try
{
    targetInfo = await GetNetworkUserInfo();
}
catch(TimeoutException) when (++retryCount <= 3)
{
    await Task.Delay(10000);
    try
    {
        targetInfo = await GetNetworkUserInfo();
    }
    catch(Exception)
    {
        try; //which "try" block does this point to?
    }
}

The try; //which "try" block does this point to?, it should retry the associated try block that it's attached to. In this case, it would retry in the inner most try block.

If we went the path of using exception filters, I'd like to see retryCount be an implicit variable (in the same way that value is for properties).

I could also see this as being retry(n); where n is the number of times to retry. That, coupled with retryCount being an implicit variables means that I don't have to write the actual retry handling logic (incrementing the counter, etc.) and can turn the above example in to:

try
{
    targetInfo = await GetNetworkUserInfo();
}
catch(TimeoutException) 
{
    await Task.Delay(10000);
    try
    {
        targetInfo = await GetNetworkUserInfo();
    }
    catch(Exception)
    {
        retry(3);
    }
}

The compiler could expand that to using the exception filter and retry looping.

[YaakovDavis]

I propose retry instead of try; should be easier to read and to analyze.

try
{
   ...
}
catch
{
   if(condition())
      retry;
}

[Logerfo]

@scottdorman both retry and retryCount would need to be new reserved keywords, which is bad for retrocompatibility. Also, I don't think try(n) is reliable, considering the try statement can appear many times in the same catch block, like that:

int retryCount = 0;
try 
{        
    targetInfo = await GetNetworkUserInfo();
}
catch(TimeoutException)
{
    await Task.Delay(10000);
    if(retryCount++ > 0)
        try(2); //will be hit at the first try
    else
        try(3); //will be hit at the second try
}

[scottdorman]

@Logerfo

both retry and retryCount would need to be new reserved keywords

retry would need to be a new contextual keyword. I don't think retryCount would since it would be compiler generated/emitted it can be named whatever we want, in the same way autoproperties generate an implicit backing field.

You also wouldn't have code like

if(retryCount++ > 0)
        try(2); //will be hit at the first try
    else
        try(3); //will be hit at the second try

retryCount isn't an accessible variable (again, just like the generated backing field for an autoprop) so you wouldn't be able to write code like that. The try(n) is simply providing the number of times to retry. In my example, it would get expanded to something like this:

{
   var ___retryCountBackingField = 0;
   try
   {
      targetInfo = await GetNetworkUserInfo();
   }
   catch(TimeoutException) 
   {
      await Task.Delay(10000);
      try
      {
         targetInfo = await GetNetworkUserInfo();
      }
      catch(Exception) when (++___retryCountBackingField <= 3)
      {
         retry(3);
      }
   }
}

[Logerfo]

retryCount isn't an accessible variable

yes it is, I've declared it:

int retryCount = 0;

I've used this variable just to exemplify a code flow possibility involving multiple try(n) with different n being called on each retry.

[scottdorman]

@Logerfo In your example, yes, you've declared it. In my suggestion, I'm saying that you wouldn't have it/need it as it would be automatically generated. Since it's not an accessible variable, you wouldn't be able to have code like you're suggesting. Yes, you could still have multiple retry(n) statements if you had multiple catch handlers, but each of those retry statements would generate a different backing field (which is what It think you'd want anyway in your example since different conditions could have different retry strategies) and each of the associated catch statements would have the appropriate exception filter applied to it.

[Logerfo]

@scottdorman what I'm trying to say is that the condition to flow to different try(n) statements does not necessarily depends on the retry count. Also, I'm talking about multiple try(n) statements in the same catch block. What would happen when the code reach try(2) on the first attempt and try(3) on the second attempt? That's why I think the parameter doesn't fit.

[scottdorman]

Here is another example:

{
    var ___retryCountBackingField1 = 0;
    var ___retryCountBackingField2 = 0;
    var ___retryCountBackingField3 = 0;

    try // outer
    {
        targetInfo = await GetNetworkUserInfo();
    }
    catch (TimeoutException) when (++___retryCountBackingField1 <= 4)
    {
        await Task.Delay(10000);
        try // inner
        {
            targetInfo = await GetNetworkUserInfo();
        }
        catch (NullReferenceException) when (++___retryCountBackingField2 <= 3)
        {
            retry(3); // retries the "inner" try block up to 3 times.
        }
        catch (System.Net.HttpListenerException) when (++___retryCountBackingField3 <= 2)
        {
            retry(2); // retries the "inner" try block up to 2 times.
        }

        retry(4); // retries the "outer" try block up to 4 times.
    }
}

This still has two try blocks, one nested inside the other, and the inner most try block has multiple catch handlers. I think this covers the scenario you described and I think it will still work properly.

If the "inner" try block catches a NullReferenceException it will retry. If, on that retry, it catches another NullReferenceException, it will retry again, and it will keep retrying as long as it continues getting NullReferenceException up to 3 times. If it gets an HttpListenerException during one of those tries, it will still retry that, but up to 2 times (as long as it keeps getting an HttpListenerException).

So, the retry and counter variable is specific to the exception type your handling and only gets incremented/retried when you encounter that exception. In this example, if the inner most try block threw something other than NullReferenceException or HttpListenerException neither of those catch handlers would be hit, so the retry(4) would be the only one that comes in to play.

[GeirGrusom]

I've been a little bit disappointed by how much we've been focusing on my example rather than the proposal itself. The idea here isn't specifically to solve the 'retry count' problem, but more generally be able to re-run a try expression for whatever reason.

In my opinion the finally block should only be run once when the code runs out of the try..catch, not for every retry. You can't express this in C# currently since placing a label in the try block is inaccessible from the catch block.

[iam3yal]

@GeirGrusom How often you find yourself handle exceptions and how often you need to recover from them?

[GeirGrusom]

@eyalsk I don't actually do it that often but I don't use continue that often either, or dynamic. I also don't find pattern matching that useful in practice (Kotlin has it) besides matching on types and specific values. All examples are always really contrived to show the usefulness of the feature. Still there is a huge effort in implementing it in C# even though I at least think it's a feature that's more awesome on paper than in practice.

This feature on the other hand is very small, and it is at least able to do something you otherwise can't express without rearranging code. You can't loop without rerunning the finally and you can't goto inside the try block.

Not every proposal has to be something you use every day. Features that saves you from writing awkward code once in a while also has merit.

[iam3yal]

@GeirGrusom

Not every proposal has to be something you use every day. Features that saves you from writing awkward code once in a while also has merit.

Well, I don't disagree, I just think that if you don't use it everyday and use it once in a while then the feature should have a much bigger impact for them to consider it but I could be wrong. :)

[GeirGrusom]

Sure. I'm not exactly heavily invested in this. I implemented this feature in a DSL I made but in that language, it's a more common case because it was designed to give a simple solution for when credit card charge fails on subscriptions. C# can't do that but I still thought it's a little odd to have try without a retry.

Well kids, you tried your best and failed miserably. The lesson is: never try.

So I'll readily admit that it's not really a huge issue, and I wouldn't exactly shed a tear if it's not implemented. It just seems like it's a fairly obvious piece that's missing among continue, break and throw so I thought I would suggest it.

edit: maybe I have to explain why C# can't do what the DSL does: it's because the DSL stores its state on await so it can wait for days or months before continuing script execution.

[ashmind]

Is there some way we can move the original proposal forward?
Just a retry without any counts, goes back to try.

It's not that common, but just ran into it again and it's kind of awkward to implement otherwise.
I feel I might code retries more often if it didn't require loops (+extra level of nesting) or a helper.

[fuzzzeee]

I would like to see this become part of the language.. but in the meantime you can roll your own.

This class can be used to wrap up the retry logic and extended to create reusable retry configurations.

    public class TryHard
    {
        private int _attempts = 3;

        /// <summary>
        /// The total number of attempts to make. Defaults to 3
        /// </summary>
        public int Attempts
        {
            get => _attempts;
            set
            {
                if (Attempts != value)
                {
                    if (value < 1)
                        throw new ArgumentOutOfRangeException(nameof(value), value, "Attempts cannot be less than 1");
                    _attempts = value;
                }
            }
        }

        /// <summary>
        /// The conditions which will result in another attempt
        /// </summary>
        public virtual ICollection<Func<Exception, bool>> ExceptionFilters { get; } = new List<Func<Exception, bool>>();

        /// <summary>
        /// The action to take between attempts. Defaults to an exponential delay
        /// </summary>
        public virtual Action<int> BetweenAttempts { get; set; } = n => Thread.Sleep(TimeSpan.FromSeconds(n * n));

        public void Attempt(Action action)
        {
            Exception lastException = null;
            for (var attempt = 0; attempt < Attempts; attempt++)
            {
                try
                {
                    action();
                    lastException = null;
                    break;
                }
                catch (Exception e) when (ExceptionFilters.Any(f => f(e)))
                {
                    lastException = e;
                    BetweenAttempts(attempt + 1);
                }
            }
            if (lastException != null)
                throw lastException;
        }
    }

[bondsbw]

If the goal is to loop, we could have try/while in the spirit of do/while:

try
{
    ...
}
while catch (Exception ex)
{
    ...
}
finally { ... }

[bondsbw]

Three attempts (explicit loop condition):

int x = 0;
try
{
   ...
}
while catch (Exception ex)
{
   ...
}
while (++x < 3);

[bondsbw]

A few thoughts on try/while:

• finally is only invoked once (upon any exit) and may not precede while catch
• Multiple while catch blocks are permitted
• Only one while with a loop condition is permitted
• Due to ambiguity, while with a loop condition must either include a semicolon, or precede finally
  • Maybe we don't allow while with semicolon... forgetting the semicolon could yield valid but incorrect code... we could move it above any while catch blocks

[bugproof]

use https://github.com/App-vNext/Polly
https://stackoverflow.com/questions/1563191/cleanest-way-to-write-retry-logic

Not sure if it should be a part of the language though. If so, maybe a keyword like retry would be better here so it could work inside while loops too.

while(something)
{
    if (something fails) retry; // would retry iteration
}

I don't think there's any language with out of the box support for resilience

[FiniteReality]

In my experience, most cases where something fails sporadically, especially when accessing network resources, are locations where you'd want to implement some sort of backoff, to prevent causing an effective denial of service attack. I don't see any easy way to implement that with this suggestion, that wouldn't be just as easy to write without it. As such, I don't think this a suitable feature for C# - it implements too little to be useful, in my opinion.

I feel the suggestion posted by @chrisaut is likely the best compromise here for those who want this - gotos are not necessarily evil when used correctly, and IMO, this is a perfect use case for it.

[GeirGrusom]

@FiniteReality

gotos are not necessarily evil when used correctly, and IMO, this is a perfect use case for it.

You cannot goto a label inside the try block, and jumping before it will cause the finalizer to execute.

[FiniteReality]

The latter case I didn't actually know about, but it makes sense now that I think about it. Either way, any type of loop would likely work just as well.

[mganss]

FWIW Ruby has a retry keyword. Also the only language I know of that has builtin syntax for this scenario. Are there others?