非递归Retry函数实现合理性探讨及优化建议

首先，你的实现核心思路是合理的——利用Scala的惰性序列（view）来避免提前执行所有重试，符合非递归的要求，并且最终返回Try[T]也能很好地封装成功/失败结果。不过它存在几个可以改进的地方，我们一步步拆解：

原实现的潜在问题 #

1. 不必要的重复执行：
   你的代码用了partition来拆分成功/失败的尝试，但partition会遍历整个惰性序列——哪怕第一次调用就成功了，它还是会执行剩下的retries-1次fun调用。这完全违背了重试的初衷（只有失败时才重试），会造成资源浪费或不符合预期的副作用（比如重复调用接口、打印日志等）。

2. 边界情况未处理：
   当retries = 0时，0 until 0是空序列，partition后a和b都是空集合，调用a.last会直接抛出NoSuchElementException，程序崩溃。

3. 代码可读性待提升：
   模式匹配的写法略显冗长，第一次读代码需要花时间理解partition后的分支逻辑。

优化后的实现 #

我们可以用foldLeft结合提前返回的逻辑，实现更高效、更健壮的重试——既保证惰性执行（成功后立刻停止），又能处理边界情况，代码也更清晰：

import scala.util.{Try, Success, Failure}

def withRetries[T](retries: Short)(fun: => T): Try[T] = {
  // 确保至少执行一次（即使retries传入0或负数）
  val maxAttempts = retries.toInt.max(1)
  
  (1 to maxAttempts).foldLeft[Try[T]](Failure(new IllegalStateException("Initial state"))) { (_, _) =>
    val currentAttempt = Try(fun)
    // 一旦成功，直接返回，终止后续重试
    if (currentAttempt.isSuccess) return currentAttempt
    // 失败则继续，保留当前失败结果
    currentAttempt
  }
}

如果偏好更简洁的写法，也可以用Iterator的find方法，但要注意副作用问题：

def withRetries[T](retries: Short)(fun: => T): Try[T] = {
  val maxAttempts = retries.toInt.max(1)
  val attempts = Iterator.fill(maxAttempts)(Try(fun))
  attempts.find(_.isSuccess).getOrElse(attempts.toList.last)
}

⚠️ 注意：第二个版本中，如果所有尝试都失败，attempts.toList会重新遍历一次迭代器（因为Iterator是一次性的），所以如果fun有副作用（比如接口调用、日志输出），会执行两次maxAttempts次。如果fun是无副作用的纯函数，这个版本没问题；如果有副作用，优先选择第一个foldLeft的版本。

关键优化点说明 #

1. 提前终止重试：
   一旦某次调用成功，立刻返回结果，不再执行后续的重试逻辑，避免不必要的资源消耗。

2. 边界情况处理：
   通过retries.toInt.max(1)确保即使传入0或负数，也至少执行一次目标函数，避免空序列导致的异常。

3. 可读性提升：
   逻辑更直观——要么找到第一个成功的结果，要么返回最后一次失败的结果，代码结构清晰易懂。

4. 灵活性保留：
   依然保持非递归的实现方式，符合你的需求，同时返回Try[T]的设计也能让调用方方便地处理成功/失败场景。

内容的提问来源于stack exchange，提问作者Michael