对失败的 Scala 期货中抛出异常感到困惑答案

【问题标题】：Confused about exception throwing in failed Scala futures对失败的 Scala 期货中抛出异常感到困惑
【发布时间】：2014-08-17 04:47:35
【问题描述】：

我有以下代码：

  private def getAPIResult(token: String, apiCall: String):Future[JsValue] = {
    WS.url(apiCall)
      .withHeaders("Authorization" -> ("Bearer " + token))
      .get().map(response =>
        response.status match {
          case 200 => Json.parse(response.body)
          case 401 => throw new RuntimeException("Authorization failed, we really need to handle this: " + response.body)
          case _ => throw new RuntimeException("Web service call failed: " + response.body)
        }
      )
  }

我需要处理两种失败情况 - 一种是我收到 HTTP 401 响应，另一种是其他更通用的错误。

我确定我已经读过在函数式编程中抛出异常是“不好的做法”，但我在这里就是这样做的吗？我不就是在辜负未来吗？

我需要能够处理 401 响应，因此我正在考虑创建一个新的异常类（称为 UnauthorizedException 之类的东西），以便调用 getApiResult 的方法可以区分 401 和任何其他错误。不过，在我这样做之前，我想确保使用这样的异常被认为是一种好的做法，或者是否有更好的方法来做到这一点。

【问题讨论】：

它完全有效。未来的失败通过组合传播，并且可以以与完成相同的方式进行处理。

标签： scala

【解决方案1】：

我确定我已经读过在函数式编程中抛出异常是“不好的做法”，但我在这里就是这样做的吗？我不就是在辜负未来吗？

失败的未来只是一种价值。抛出异常通常被认为是一种不好的做法，因为它不表现得像返回一个值。

我需要能够处理 401 响应，因此我正在考虑创建一个新的异常类（称为 UnauthorizedException 之类的东西），以便调用 getApiResult 的方法可以区分 401 和任何其他错误。不过，在我这样做之前，我想确保使用这样的异常被认为是一种好的做法，或者是否有更好的方法来做到这一点。

是的，完全没问题。一个问题是从签名中看不出UnauthorizedException需要单独处理。

对于私有 API，这无关紧要。如果你仍然想避免它，你可以做类似的事情

sealed trait Response

case class Ok(value: JsValue) extends Response

case class Unauthorized extends Response

// possible
case class OtherError(e: Exception) extends Response

private def getAPIResult(token: String, apiCall: String):Future[Response] = ...

当然，现在所有客户都必须处理它。

【讨论】：