6年后更新:现在我认为下面的方法非常糟糕。为了创建重试逻辑，我们应该考虑使用Polly这样的库。

重试方法的异步实现:

public static async Task<T> DoAsync<T>(Func<dynamic> action, TimeSpan retryInterval, int retryCount = 3)
    {
        var exceptions = new List<Exception>();

        for (int retry = 0; retry < retryCount; retry++)
        {
            try
            {
                return await action().ConfigureAwait(false);
            }
            catch (Exception ex)
            {
                exceptions.Add(ex);
            }

            await Task.Delay(retryInterval).ConfigureAwait(false);
        }
        throw new AggregateException(exceptions);
    }

重点:我使用。configureawait (false);和Func<dynamic>代替Func<T>

6年后更新:现在我认为下面的方法非常糟糕。为了创建重试逻辑，我们应该考虑使用Polly这样的库。

重试方法的异步实现:

public static async Task<T> DoAsync<T>(Func<dynamic> action, TimeSpan retryInterval, int retryCount = 3)
    {
        var exceptions = new List<Exception>();

        for (int retry = 0; retry < retryCount; retry++)
        {
            try
            {
                return await action().ConfigureAwait(false);
            }
            catch (Exception ex)
            {
                exceptions.Add(ex);
            }

            await Task.Delay(retryInterval).ConfigureAwait(false);
        }
        throw new AggregateException(exceptions);
    }

重点:我使用。configureawait (false);和Func<dynamic>代替Func<T>

我使用Polly实现了该模式的两个实现。其一是异步。

我的同步方法是基于Erik Bergstedt的回答

public static T Retry<T>(Func<T> action, TimeSpan retryWait, int retryCount = 0)
{
    PolicyResult<T> policyResult = Policy
        .Handle<ApiException>(ex => ex.ResponseCode == (int)HttpStatusCode.TooManyRequests)
        .WaitAndRetry(retryCount, retryAttempt => retryWait)
        .ExecuteAndCapture(action);

    if (policyResult.Outcome == OutcomeType.Failure)
    {
        throw policyResult.FinalException;
    }

    return policyResult.Result;
}

异步:

public static async Task<T> RetryAsync<T>(Func<Task<T>> action, TimeSpan retryWait, int retryCount = 0)
{
    PolicyResult<T> policyResult = await Policy
        .Handle<ApiException>(ex => ex.ResponseCode == (int)HttpStatusCode.TooManyRequests)
        .WaitAndRetryAsync(retryCount, retryAttempt => retryWait)
        .ExecuteAndCaptureAsync(action);

    if (policyResult.Outcome == OutcomeType.Failure)
    {
        throw policyResult.FinalException;
    }

    return policyResult.Result;
}

允许传入异常类型以及异常类型的lambda也很容易。

这可能是个坏主意。首先，这是一句格言的象征:“疯狂的定义是做同一件事两次，每次都期待不同的结果”。其次，这种编码模式本身不能很好地组合。例如:

假设您的网络硬件层在失败时重发一个数据包三次，在两次失败之间等待一秒钟。

现在假设软件层在包失败时重发关于失败的通知三次。

现在假设通知层在通知传递失败时重新激活通知三次。

现在假设错误报告层在通知失败时重新激活通知层三次。

现在假设web服务器在错误失败时重新激活错误报告三次。

现在假设web客户端在从服务器得到错误后重新发送请求三次。

现在假设网络交换机上用来将通知路由到管理员的线路被拔掉。web客户端的用户什么时候最终得到错误消息?我大约12分钟后到。

以免您认为这只是一个愚蠢的例子:我们已经在客户代码中看到了这个错误，尽管比我在这里描述的要严重得多。在特定的客户代码中，错误条件发生和最终报告给用户之间的间隔是几个星期，因为有很多层自动重试并等待。想象一下，如果是十次而不是三次，会发生什么。

通常正确的处理错误的方法是立即报告它，让用户决定怎么做。如果用户想要创建自动重试的策略，让他们在软件抽象的适当级别上创建该策略。

您还可以考虑添加要重试的异常类型。例如，这是您想要重试的超时异常吗?数据库异常?

RetryForExcpetionType(DoSomething, typeof(TimeoutException), 5, 1000);

public static void RetryForExcpetionType(Action action, Type retryOnExceptionType, int numRetries, int retryTimeout)
{
    if (action == null)
        throw new ArgumentNullException("action");
    if (retryOnExceptionType == null)
        throw new ArgumentNullException("retryOnExceptionType");
    while (true)
    {
        try
        {
            action();
            return;
        }
        catch(Exception e)
        {
            if (--numRetries <= 0 || !retryOnExceptionType.IsAssignableFrom(e.GetType()))
                throw;

            if (retryTimeout > 0)
                System.Threading.Thread.Sleep(retryTimeout);
        }
    }
}

您可能还注意到，所有其他示例在测试retries == 0时都存在类似的问题，要么重试无穷大，要么在给定负值时无法引发异常。Sleep(-1000)在上面的catch块中也会失败。这取决于你期望人们有多“愚蠢”，但防御性编程永远不会伤害到你。

我知道这个答案很老了，但我只是想对此进行评论，因为我在使用这些while, do, whatever语句时遇到了问题。

多年来，我认为我找到了一个更好的方法。这就是使用某种事件聚合，如响应式扩展“Subject”或类似的。当尝试失败时，只需发布一个事件，说明尝试失败，并让聚合器函数重新调度该事件。这使您可以更好地控制重试，而不会用一堆重试循环或其他东西污染调用本身。你也不是用一堆线程来捆绑一个线程。