3

这可能是一个非常愚蠢的问题，但我试图了解在 Finatra 的 HttpClient定义中的此方法定义中使用#flatMap而不仅仅是#map背后的逻辑：

def executeJson[T: Manifest](request: Request, expectedStatus: Status = Status.Ok): Future[T] = {
  execute(request) flatMap { httpResponse =>
    if (httpResponse.status != expectedStatus) {
      Future.exception(new HttpClientException(httpResponse.status, httpResponse.contentString))
    } else {
      Future(parseMessageBody[T](httpResponse, mapper.reader[T]))
        .transformException { e =>
          new HttpClientException(httpResponse.status, s"${e.getClass.getName} - ${e.getMessage}")
        }
    }
  }
}

当我可以只使用#map而不是拥有类似的东西时，为什么要创建一个新的 Future ：

execute(request) map { httpResponse =>
  if (httpResponse.status != expectedStatus) {
    throw new HttpClientException(httpResponse.status, httpResponse.contentString)
  } else {
    try {
      FinatraObjectMapper.parseResponseBody[T](httpResponse, mapper.reader[T])
    } catch {
      case e => throw new HttpClientException(httpResponse.status, s"${e.getClass.getName} - ${e.getMessage}")
    }
  }
}

这是否纯粹是一种风格上的差异，在这种情况下使用 Future.exception 只是更好的风格，而抛出几乎看起来像一个副作用（实际上它不是，因为它没有退出 Future 的上下文）或者存在它背后的东西，例如执行顺序等？

Tl; dr：在 Future 中抛出与返回 Future.exception 有什么区别？

4

2 回答 2

3

从理论的角度来看，如果我们去掉异常部分（无论如何都不能推断出使用范畴论），那么只要您选择的构造（在您的情况下为 Twitter Future）形成一个有效的单子，这两个操作就完全相同.

我不想详细介绍这些概念，所以我将直接介绍这些法律（使用 Scala Future）：

import scala.concurrent.ExecutionContext.Implicits.global

// Functor identity law
Future(42).map(x => x) == Future(42)

// Monad left-identity law
val f = (x: Int) => Future(x)
Future(42).flatMap(f) == f(42) 

// combining those two, since every Monad is also a Functor, we get:
Future(42).map(x => x) == Future(42).flatMap(x => Future(x))

// and if we now generalise identity into any function:
Future(42).map(x => x + 20) == Future(42).flatMap(x => Future(x + 20))

所以是的，正如您已经暗示的那样，这两种方法是相同的。

但是，鉴于我们将例外情况纳入其中，我对此有三点评论：

  1. 小心——当涉及到抛出异常时，Scala Future（也可能是 Twitter）故意违反左标识法，以换取一些额外的安全性。

例子：

import scala.concurrent.ExecutionContext.Implicits.global

def sneakyFuture = {
  throw new Exception("boom!")
  Future(42)
}

val f1 = Future(42).flatMap(_ => sneakyFuture)
// Future(Failure(java.lang.Exception: boom!))

val f2 = sneakyFuture
// Exception in thread "main" java.lang.Exception: boom!
  1. 正如@randbw 所提到的，抛出异常对于 FP 来说不是惯用的，它违反了函数纯度和值的引用透明性等原则。

Scala 和 TwitterFuture使您可以轻松地抛出异常——只要它发生在Future上下文中，异常就不会冒泡，而是会导致Future失败。但是，这并不意味着应该允许在代码中直接扔掉它们，因为它会破坏程序的结构（类似于 GOTO 语句的执行方式，或循环中的 break 语句等）。

首选做法是始终将每个代码路径评估为一个值，而不是到处乱扔炸弹，这就是为什么将 flatMap 转换为（失败的）Future比映射到一些抛出炸弹的代码更好的原因。

  1. 请记住参考透明度。

如果您使用map而不是flatMap并且有人从地图中获取代码并将其提取到函数中，那么如果此函数返回 a ，您会更安全Future，否则有人可能会在Future上下文之外运行它。

例子：

import scala.concurrent.ExecutionContext.Implicits.global

Future(42).map(x => {
  // this should be done inside a Future
  x + 1
})

这可以。但是在完全有效的重构（利用引用透明规则）之后，你的代码变成了这样：

def f(x: Int) =  {
  // this should be done inside a Future
  x + 1
}
Future(42).map(x => f(x))

如果有人直接打电话，你会遇到问题f。将代码包装成 aFuture和 flatMap 会更安全。

当然，您可以争辩说，即使使用flatMap某人也可以撕掉ffrom .flatMap(x => Future(f(x))，但这不太可能。另一方面，简单地将响应处理逻辑提取到一个单独的函数中，完全符合函数式编程将小函数组合成大函数的想法，而且这种情况很有可能发生。

于 2020-11-25T09:34:34.410 回答
1

根据我对 FP 的理解，不会抛出异常。正如你所说，这将是一个副作用。相反，异常是在程序执行的某个时刻处理的值。

Cats（我相信其他库也一样）也采用了这种技术（https://github.com/typelevel/cats/blob/master/core/src/main/scala/cats/ApplicativeError.scala）。

因此，flatMap调用允许异常包含在此处满足的 Future 中，并在程序执行的稍后时间点进行处理，其中也可能发生其他异常值处理。

于 2020-11-25T08:49:19.983 回答