【问题标题】:Is there a way to compose potentially failing operations in Go?有没有办法在 Go 中组合可能失败的操作?
【发布时间】:2017-08-28 17:19:48
【问题描述】:

我阅读的大多数 go 代码都经常出现以下模式:

result1, err := failingOp1()
if err != nil {
    return err
}
dependingResult, err := failingOp2(result1)
if err != nil {
    return err
}
// do stuff with dependingResult

在函数式编程中,我们有 Either monad 及其表亲(例如 Scala 的 Try),它们允许我们组合失败的操作而无需不断重复自己。

是否有 go 等价物有助于整理代码?

【问题讨论】:

  • 只有我的两分钱。我发现关于立即处理错误的一些事情是它如何使代码的主要流程更容易遵循。如果一切顺利,大多数功能只是从上到下流动。我们希望它们正确,因此阅读预期的流程很容易。 “缩进错误,而不是代码”和删除 elses 的概念进一步简化了函数的阅读。大多数重要的东西只缩进一两次,所以你会得到一个很好的左对齐列来阅读。此外,函数末尾没有大括号地狱。 github.com/golang/go/wiki/CodeReviewComments

标签: go error-handling either


【解决方案1】:

进一步阅读,特别是 this SO answer,似乎惯用的 go 更喜欢在调用站点处理错误,而不是向上传播潜在错误(单子方法有利于)。

按照这个思路:

func wrapFailingOp1() ResultType {
  result1, err := failingOp1()
  if err != nil {
    return defaultRTOrPanic()
  }
  return result1
}

func wrapFailingOp2(result1 ResultType) DependingResultType {
    dependingResult, err := failingOp2(result1)
    if err != nil {
        return defaultDRTOrPanic()
    }
    return dependingResult
}

x := wrapFailingOp1()
y := wrapFailingOp2(x)

【讨论】:

    猜你喜欢
    • 2021-07-26
    • 1970-01-01
    • 2019-09-07
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2012-04-06
    • 1970-01-01
    相关资源
    最近更新 更多