我同意这是最好的方法：用简单的设计解决最常见的问题。

我不想骑自行车（请随意推迟这个对话），但 Rust 去了那里并最终解决了?后缀运算符而不是内置函数，以提高可读性。

gophercon 提案在考虑的想法中引用了?并给出了它被丢弃的三个原因：第一个（“控制流传输作为一般规则伴随关键字”）和第三个（“处理程序更自然地定义带有关键字，因此检查也应该“）不再适用。 第二个是文体：它说，即使后缀运算符更适合链接，它在某些情况下仍然可能读起来更糟，例如：

check io.Copy(w, check newReader(foo))

而不是：

io.Copy(w, newReader(foo)?)?

但现在我们将拥有：

try(io.Copy(w, try(newReader(foo))))

我认为这显然是三者中最糟糕的，因为它不再明显是被调用的主要函数。

所以我评论的要点是 gophercon 提案中提到的不使用?的所有三个原因都不适用于这个try提案； ?简洁，可读性强，不会混淆语句结构（具有内部函数调用层次结构），并且是可链接的。 它从视图中消除了更多的混乱，同时不会比建议的try()已经做的更模糊控制流。

澄清：

做

func f() (n int, err error) {
  n = 7
  try(errors.New("x"))
  // ...
}

返回（0，“x”）还是（7，“x”）？ 我假设后者。

在没有装饰或处理的情况下（如在内部辅助函数中）是否必须命名错误返回？ 我假设不是。

您的示例返回7, errors.New("x") 。 这应该在即将提交的完整文档中明确（https://golang.org/cl/180557）。

不需要命名错误结果参数即可使用try 。 仅当函数需要在延迟函数或其他地方引用它时才需要命名。

我对影响调用者控制流的内置函数非常不满意。 我很欣赏在 Go 1 中添加新关键字是不可能的，但是用魔法内置函数解决这个问题对我来说似乎是错误的。 其他内置插件的阴影不会产生像控制流变化那样不可预测的结果。

我不喜欢后缀?的样子，但我认为它仍然胜过try() 。

编辑：好吧，我设法完全忘记了恐慌的存在并且不是关键字。

详细的建议现在在这里（等待格式改进，很快就会出现），希望能回答很多问题。

@dominikh详细的提案详细讨论了这一点，但请注意panic和recover也是影响控制流的两个内置函数。

一项澄清/改进建议：

if the last argument supplied to try, of type error, is not nil, the enclosing function’s error result variable (...) is set to that non-nil error value before the enclosing function returns

这可以改为is set to that non-nil error value and the enclosing function returns吗？ (s/之前/和)

初读时， before the enclosing function returns似乎会_最终_在函数返回之前的某个时间点设置错误值——可能在后面的一行。 正确的解释是 try 可能会导致当前函数返回。 对于当前语言来说，这是一个令人惊讶的行为，因此欢迎使用更清晰的文本。

我认为这只是糖，有少数声音反对者嘲笑 golang 重复使用键入if err != nil ...并且有人认真对待。 我不认为这是一个问题。 唯一缺少的是这两个内置函数：

https://github.com/purpleidea/mgmt/blob/a235b760dc3047a0d66bb0b9d63c25bc746ed274/util/errwrap/errwrap.go#L26

不知道为什么有人会写这样的函数，但设想的输出是什么

try(foobar())

如果foobar返回(error, error)

我收回了我之前对控制流的担忧，我不再建议使用? 。 对于下意识的回应，我深表歉意（尽管我想指出，如果问题是在完整的提案可用后提交的，则不会发生这种情况）。

我不同意简化错误处理的必要性，但我确信这是一场失败的战斗。 提案中列出的try似乎是最不坏的方法。

@webermaster只有最后一个error结果对于传递给try的表达式是特殊的，如提案文档中所述。

像@dominikh一样，我也不同意简化错误处理的必要性。

它将垂直复杂性转变为水平复杂性，这很少是一个好主意。

但是，如果我必须在简化错误处理建议之间做出选择，这将是我的首选建议。

如果这可以伴随（在某个被接受的阶段）通过一个工具来转换 Go 代码以在错误返回函数的某些子集中使用try会很有帮助，这样的转换可以很容易地执行而无需改变语义。 我想到了三个好处：

• 在评估这个提议时，它可以让人们快速了解如何在他们的代码库中使用try 。
• 如果try出现在 Go 的未来版本中，人们可能会想要更改他们的代码以使用它。 拥有一个自动化简单案例的工具将有很大帮助。
• 有一种方法可以快速转换大型代码库以使用try将可以轻松地检查大规模实现的效果。 （例如，正确性、性能和代码大小。）但是，实现可能足够简单，可以忽略不计。

我只是想表达我认为一个简单的try(foo())实际上从调用函数中跳出来带走了我们的视觉提示，即函数流可能会根据结果而改变。

我觉得我可以使用try ，只要有足够的习惯，但我也觉得我们需要额外的 IDE 支持（或类似的支持）来突出显示try以有效识别代码审查中的隐式流程/调试会话

我最关心的是需要命名返回值，这样 defer 语句才会满意。

我认为社区抱怨的整体错误处理问题是if err != nil样板和向错误添加上下文的组合。 常见问题解答清楚地指出后者是故意作为一个单独的问题排除在外的，但我觉得这成为一个不完整的解决方案，但在考虑以下两件事后，我愿意给它一个机会：

1. 在函数的开头声明err 。
   这行得通吗？ 我记得延迟和未命名结果的问题。 如果不是，该提案需要考虑这一点。

func sample() (string, error) {
  var err error
  defer fmt.HandleErrorf(&err, "whatever")
  s := try(f())
  return s, nil
}

1. 像过去一样分配值，但使用具有if err != nil样板的帮助器wrapf函数。

func sample() (string, error) {
  s, err := f()
  try(wrapf(err, "whatever"))
  return s, nil
}
func wrapf(err error, format string, ...v interface{}) error {
  if err != nil {
    // err = wrapped error
  }
  return err
}

如果任何一个工作，我可以处理它。

func sample() (string, error) {
  var err error
  defer fmt.HandleErrorf(&err, "whatever")
  s := try(f())
  return s, nil
}

这行不通。 defer 会更新与返回值无关的本地err变量。

func sample() (string, error) {
  s, err := f()
  try(wrapf(err, "whatever"))
  return s, nil
}
func wrapf(err error, format string, ...v interface{}) error {
  if err != nil {
    // err = wrapped error
  }
  return err
}

那应该行得通。 不过，即使出现 nil 错误，它也会调用 wrapf。
这也将（继续）起作用，并且 IMO 更加清晰：

func sample() (string, error) {
  s, err := f()
  if err != nil {
      return "", wrap(err)
  }
  return s, nil
}

没有人会让你使用try 。

不知道为什么有人会写这样的函数，但设想的输出是什么

try(foobar())

如果foobar返回(error, error)

为什么你会从一个函数返回多个错误？ 如果您从函数返回多个错误，则函数可能首先应拆分为两个单独的错误，每个仅返回一个错误。

你能用一个例子详细说明吗？

@cespare ：有人应该可以编写一个go fix来重写适用于try的现有代码，以便它使用try 。 了解如何简化现有代码可能很有用。 我们预计代码大小或性能不会有任何显着变化，因为try只是语法糖，用更短的源代码替换常见模式，生成基本相同的输出代码。 另请注意，使用try的代码将绑定使用至少是引入try的版本的 Go 版本。

@lestrrat ：同意必须了解try可以更改控制流。 我们怀疑 IDE 可以很容易地突出显示这一点。

@Goodwine ：正如@randall77已经指出的那样，你的第一个建议是行不通的。 我们考虑过的一个选项（但未在文档中讨论）是有一些预先声明的变量来表示error结果（​​如果首先存在的话）的可能性。 这将消除命名该结果的需要，以便它可以在defer中使用。 但这会更神奇。 这似乎不合理。 命名返回结果的问题本质上是装饰性的，最重要的是go doc和朋友提供的自动生成的 API。 在这些工具中很容易解决这个问题（另请参阅有关此主题的详细设计文档的常见问题解答）。

@nictuku ：关于您的澄清建议（s/before/and/）：我认为您所指的段落之前的代码清楚地说明了究竟发生了什么，但我明白您的意思，s/before/and/ may使散文更清晰。 我会做出改变。

参见CL 180637 。

我真的很喜欢这个提议。 但是，我确实有一个批评。 Go 中函数的退出点总是用return标记。 恐慌也是退出点，但这些是通常不会遇到的灾难性错误。

为不是return的函数创建一个退出点，并且这意味着它是司空见惯的，可能会导致代码的可读性大大降低。 我在一次演讲中听说过这个，很难看出这段代码的结构之美：

func CopyFile(src, dst string) error {
    r, err := os.Open(src)
    if err != nil {
        return fmt.Errorf("copy %s %s: %v", src, dst, err)
    }
    defer r.Close()

    w, err := os.Create(dst)
    if err != nil {
        return fmt.Errorf("copy %s %s: %v", src, dst, err)
    }

    if _, err := io.Copy(w, r); err != nil {
        w.Close()
        os.Remove(dst)
        return fmt.Errorf("copy %s %s: %v", src, dst, err)
    }

    if err := w.Close(); err != nil {
        os.Remove(dst)
        return fmt.Errorf("copy %s %s: %v", src, dst, err)
    }
}

这段代码可能看起来很乱，并且是错误处理草案的_意思是_，但让我们将它与try进行比较。

func CopyFile(src, dst string) error {
    defer func() {
        err = fmt.Errorf("copy %s %s: %v", src, dst, err)
    }()
    r, err := try(os.Open(src))
    defer r.Close()

    w, err := try(os.Create(dst))

    defer w.Close()
    defer os.Remove(dst)
    try(io.Copy(w, r))
    try(w.Close())

    return nil
}

乍一看，你可能会觉得它看起来更好，因为重复的代码少了很多。 但是，很容易发现函数在第一个示例中返回的所有点。 它们都是缩进的，并以return开头，后跟一个空格。 这是因为所有条件返回_必须_在条件块内，因此按gofmt标准缩进。 如前所述， return也是离开函数而不说发生灾难性错误的唯一方法。 在第二个示例中，只有一个return ，因此看起来函数 _ever_ 应该返回的唯一内容是nil 。 最后两个try调用很容易看到，但前两个调用有点难，如果它们嵌套在某个地方会更难，例如proc := try(os.FindProcess(try(strconv.Atoi(os.Args[1])))) 。

从函数返回似乎是一件“神圣”的事情，这就是为什么我个人认为函数的所有退出点都应该用return标记。

5年前已经有人实施了。 如果你有兴趣，你可以
试试这个功能

https://news.ycombinator.com/item?id=20101417

五年前，我在 Go 中使用 AST 预处理器实现了 try()，并在实际项目中使用它，非常好： https ://github.com/lunixbochs/og

以下是我在错误检查繁重的功能中使用它的一些示例： https ://github.com/lunixbochs/poxd/blob/master/tls.go#L13

我很感激为此付出的努力。 我认为这是迄今为止我见过的最简单的解决方案。 但我认为它在调试时引入了一堆工作。 每次调试时打开尝试并添加一个 if 块，完成后重新包装它是乏味的。 而且我对我需要考虑的神奇 err 变量也有些畏缩。 我从来没有被明确的错误检查所困扰，所以也许我是问错人了。 它总是让我觉得“准备调试”。

@griesemer
我建议使用 defer 作为处理错误包装的方法的问题是，我展示的代码段中的行为（在下面重复）不是很常见的 AFAICT，因为它非常罕见，所以我可以想象人们写这个认为它有效当它没有的时候。

就像..初学者不会知道这一点，如果他们因此有错误，他们不会去“当然，我需要一个命名的回报”，他们会感到压力很大，因为它应该工作而它没有。

var err error
defer fmt.HandleErrorf(err);

try已经太神奇了，所以你不妨一路走下去，加上那个隐含的错误值。 考虑初学者，而不是了解围棋所有细微差别的人。 如果不够清楚，我认为这不是正确的解决方案。

或者......不要建议像这样使用 defer ，尝试另一种更安全但仍然可读的方式。

@deanveloper确实，该提案（以及就此而言，任何尝试尝试相同事情的提案）将从源代码中删除明确可见的return语句-毕竟这就是提案的重点，不是吗？ 删除相同的if语句和returns的样板。 如果要保留return ，请不要使用try 。

我们习惯于立即识别return语句（和panic的），因为这就是这种控制流在 Go（和许多其他语言）中的表达方式。 就像我们对return所做的那样，在一些人习惯了它之后，我们也会将try识别为改变控制流，这似乎并不牵强。 我毫不怀疑良好的 IDE 支持也会对此有所帮助。

我有两个担忧：

• 命名返回非常令人困惑，这鼓励他们使用新的重要用例
• 这将阻止向错误添加上下文

根据我的经验，在每个调用站点之后立即为错误添加上下文对于拥有易于调试的代码至关重要。 在某些时候，我认识的几乎所有 Go 开发人员都对命名返回造成了困惑。

一个更次要的文体问题是，不幸的是，现在有多少行代码将被包装在try(actualThing())中。 我可以想象看到包含在try()中的代码库中的大多数行。 这感觉很不幸。

我认为这些问题可以通过调整来解决：

a, b, err := myFunc()
check(err, "calling myFunc on %v and %v", a, b)

check()的行为很像try() ，但会放弃一般传递函数返回值的行为，而是提供添加上下文的能力。 它仍然会触发返回。

这将保留try()的许多优点：

• 这是一个内置的
• 它遵循现有的控制流 WRT 来推迟
• 它与为错误添加上下文的现有做法很好地保持一致
• 它与当前的错误包装建议和库保持一致，例如errors.Wrap(err, "context message")
• 它会产生一个干净的调用站点： a, b, err := myFunc()行上没有样板
• 仍然可以使用defer fmt.HandleError(&err, "msg")描述错误，但不需要鼓励。
• check的签名稍微简单一些，因为它不需要从它包装的函数返回任意数量的参数。

@s4n-gt 感谢您提供此链接。 我没有意识到这一点。

采取@Goodwine点。 设计文档中详细讨论了不提供更直接的错误处理支持的原因。 这也是一个事实，在一年左右的时间里（自去年 Gophercon 上发布的设计草案以来）没有出现令人满意的显式错误处理解决方案。 这就是为什么该提案故意将其排除在外（而是建议使用defer ）。 该提议仍然为未来在这方面的改进打开了大门。

该提案提到更改包测试以允许测试和基准测试返回错误。 虽然这不是“一个适度的库更改”，但我们也可以考虑接受func main() error 。 它会使编写小脚本变得更好。 语义相当于：

func main() {
  if err := newmain(); err != nil {
    println(err.Error())
    os.Exit(1)
  }
}

最后一点批评。 并不是对提案本身的批评，而是对对“功能控制流程”反驳的共同回应的批评。

对“我不喜欢函数控制流程”的回应是“ panic也控制程序的流程！”。 但是，有几个原因更适合panic这样做不适用于try 。

1. panic对初学者程序员很友好，因为它的作用很直观，它会继续展开堆栈。 甚至不必查看panic的工作原理即可了解它的作用。 初学者甚至不需要担心recover ，因为初学者通常不会建立恐慌恢复机制，特别是因为它们几乎总是不如一开始就避免恐慌。

2. panic是一个很容易看到的名字。 它带来了担忧，而且它需要。 如果有人在代码库中看到panic ，他们应该立即考虑如何_避免_恐慌，即使它是微不足道的。

3. 捎带最后一点， panic不能嵌套在调用中，使其更容易查看。

恐慌控制程序的流程是可以的，因为它非常容易发现，而且它的作用很直观。

try函数不满足这些点。

1. 如果不查找文档，就无法猜测try做了什么。 许多语言以不同的方式使用关键字，因此很难理解它在 Go 中的含义。

2. try没有引起我的注意，尤其是当它是一个函数时。 _特别是_当语法高亮将它作为一个函数高亮时。 _特别是在使用 Java 等语言进行开发后，其中try被视为不必要的样板文件（因为已检查的异常）。

3. try可以在函数调用的参数中使用，就像我在之前的评论proc := try(os.FindProcess(try(strconv.Atoi(os.Args[1]))))中的示例一样。 这使得它更难被发现。

我的眼睛忽略了try功能，即使我专门寻找它们。 我的眼睛会看到它们，但会立即跳到os.FindProcess或strconv.Atoi调用。 try是有条件的回报。 在 Go 中，控制流和返回都被固定在基座上。 函数内的所有控制流都是缩进的，所有返回都以return开头。 将这两个概念混合在一起形成一个容易错过的函数调用，感觉有点不对劲。

不过，这条评论和我的最后一条评论是我对这个想法的唯一真正批评。 我想我可能不喜欢这个提议，但我仍然认为这对 Go 来说是一个整体的胜利。 这个解决方案仍然比其他解决方案更像 Go。 如果添加了这个我会很高兴，但是我认为它仍然可以改进，我只是不确定如何。

@buchanae很有趣。 但是，正如所写的那样，它将 fmt 样式的格式从一个包移到了语言本身，这打开了一个蠕虫罐。

但是，正如所写的那样，它将 fmt 样式的格式从一个包移到了语言本身，这打开了一个蠕虫罐。

好点子。 一个更简单的例子：

a, b, err := myFunc()
check(err, "calling myFunc")

@buchanae我们考虑过使显式错误处理与try更直接相关 - 请参阅详细的设计文档，特别是有关设计迭代的部分。 如果我理解正确，您对check的具体建议只会允许通过类似fmt.Errorf之类的 API（作为check的一部分）来增加错误。 一般来说，人们可能想做各种有错误的事情，而不仅仅是创建一个通过错误字符串引用原始错误的新错误。

同样，这个提议并没有试图解决所有的错误处理情况。 我怀疑在大多数情况下try对于现在看起来基本上像这样的代码是有意义的：

a, b, c, ... err := try(someFunctionCall())
if err != nil {
   return ..., err
}

有很多看起来像这样的代码。 并不是每一段看起来像这样的代码都需要更多的错误处理。 在defer不正确的地方，仍然可以使用if语句。

我不遵循这条线：

defer fmt.HandleErrorf(&err, “foobar”)

它将入站错误丢弃在地板上，这是不寻常的。 是否打算使用更像这样的东西？

defer fmt.HandleErrorf(&err, “foobar: %v”, err)

err 的重复有点口吃。 这并不是真正直接适合该提案，只是对文档的附带评论。

我分享了@buchanae提出的两个问题，即：命名返回和上下文错误。

我发现命名返回有点麻烦。 我认为它们仅作为文档才真正有益。 更严重地依赖它们是一种担忧。 不过，很抱歉这么含糊。 我会更多地考虑这一点，并提供一些更具体的想法。

我确实认为人们会努力构建他们的代码以便可以使用try ，从而避免在错误中添加上下文，这是一个真正的担忧。 这是一个特别奇怪的时间来介绍这一点，因为我们刚刚提供了更好的方法来通过官方错误包装功能为错误添加上下文。

我确实认为所提议的try使一些代码变得更好。 这是我从当前项目的代码库中或多或少随机选择的一个函数，其中一些名称已更改。 在分配给结构字段时， try的工作方式给我留下了特别深刻的印象。 （这是假设我对提案的阅读是正确的，并且这有效？）

现有代码：

func NewThing(thingy *foo.Thingy, db *sql.DB, client pb.Client) (*Thing, error) {
        err := dbfile.RunMigrations(db, dbMigrations)
        if err != nil {
                return nil, err
        }
        t := &Thing{
                thingy: thingy,
        }
        t.scanner, err = newScanner(thingy, db, client)
        if err != nil {
                return nil, err
        }
        t.initOtherThing()
        return t, nil
}

使用try ：

func NewThing(thingy *foo.Thingy, db *sql.DB, client pb.Client) (*Thing, error) {
        try(dbfile.RunMigrations(db, dbMigrations))
        t := &Thing{
                thingy:  thingy,
                scanner: try(newScanner(thingy, db, client)),
        }
        t.initOtherThing()
        return t, nil
}

不损失可读性，除了newScanner可能会失败的情况可能不太明显。 但是在一个有try的世界里，Go 程序员会对它的存在更加敏感。

@josharian关于main返回error ：在我看来，您的小助手功能就是获得相同效果所需的全部。 我不确定更改main的签名是否合理。

关于“foobar”的例子：这只是一个坏例子。 我可能应该改变它。 谢谢你提出来。

defer fmt.HandleErrorf(&err, “foobar: %v”, err)

实际上，这是不对的，因为err将被过早地评估。 有几种方法可以解决这个问题，但没有一个像原始的（我认为有缺陷的）HandleErrorf 那样干净。 我认为最好有一个或两个辅助函数的更现实的工作示例。

编辑：这个早期评估错误出现在一个例子中
在文档末尾附近：

defer fmt.HandleErrorf(&err, "copy %s %s: %v", src, dst, err)

@adg是的， try可以在您的示例中使用它。 我让你的评论重新：命名的回报保持原样。

人们可能想用错误来做各种各样的事情，而不仅仅是创建一个通过错误字符串引用原始错误的新错误。

try不会尝试处理人们想要处理错误的所有类型的事情，只会处理那些我们可以找到一种实用的方法来显着简化的事情。 我相信我的check示例也是如此。

根据我的经验，最常见的错误处理代码形式是本质上添加堆栈跟踪的代码，有时还会添加上下文。 我发现堆栈跟踪对于调试非常重要，我通过代码跟踪错误消息。

但是，也许其他提案会为所有错误添加堆栈跟踪？ 我迷路了。

在@adg给出的示例中，有两个潜在的失败，但没有上下文。 如果newScanner和RunMigrations本身不提供提示您哪个出错的消息，那么您只能猜测。

在@adg给出的示例中，有两个潜在的失败，但没有上下文。 如果 newScanner 和 RunMigrations 本身不提供提示您出错的消息，那么您只能猜测。

没错，这就是我们在这段特定代码中所做的设计选择。 我们确实在代码的其他部分包含了很多错误。

我与@deanveloper和其他人一样担心它可能会使调试变得更加困难。 确实可以选择不使用，但是第三方依赖的样式不是我们能控制的。
如果重复较少的if err := ... { return err }是主要观点，我想知道“有条件的回报”是否就足够了，就像建议的https://github.com/golang/go/issues/27794一样。

        return nil, err if f, err := os.Open(...)
        return nil, err if _, err := os.Write(...)

我认为?会比try更合适，并且总是不得不追逐defer的错误也很棘手。

这也为永远使用try/catch的异常关闭了大门。

这也为永远使用 try/catch 的异常关闭了大门。

我_more_对此感到满意。

我同意上面提出的一些关于为错误添加上下文的担忧。 我正在慢慢尝试从仅返回错误转变为始终用上下文装饰它然后返回它。 有了这个提议，我将不得不完全改变我的函数以使用命名返回参数（我觉得这很奇怪，因为我几乎不使用裸返回）。

正如@griesemer所说：

同样，这个提议并没有试图解决所有的错误处理情况。 我怀疑在大多数情况下 try 对于现在看起来基本上像这样的代码是有意义的：
a, b, c, ... 错误 := try(someFunctionCall())
如果错误！= nil {
返回...，错误
}
有很多看起来像这样的代码。 并不是每一段看起来像这样的代码都需要更多的错误处理。 在 defer 不正确的地方，仍然可以使用 if 语句。

是的，但不应该是好的，惯用的代码总是包装/装饰他们的错误吗？ 我相信这就是我们引入改进的错误处理机制以在 stdlib 中添加上下文/包装错误的原因。 如我所见，这个提议似乎只考虑了最基本的用例。

此外，该提案仅解决了在一个_single place_处包装/装饰多个可能的错误返回站点的情况，使用带有延迟调用的命名参数。

但是对于需要在单个函数中为不同的错误添加不同的上下文的情况，它没有任何作用。 例如，装饰数据库错误以获取有关它们来自何处的更多信息非常重要（假设没有堆栈跟踪）

这是我拥有的真实代码的示例-

func (p *pgStore) DoWork() error {
    tx, err := p.handle.Begin()
    if err != nil {
        return err
    }
    var res int64
    err = tx.QueryRow(`INSERT INTO table (...) RETURNING c1`, ...).Scan(&res)
    if err != nil {
        tx.Rollback()
        return fmt.Errorf("insert table: %w", err)
    }

    _, err = tx.Exec(`INSERT INTO table2 (...) VALUES ($1)`, res)
    if err != nil {
        tx.Rollback()
        return fmt.Errorf("insert table2: %w", err)
    }
    return tx.Commit()
}

根据提案：

如果需要错误增加或包装，有两种方法：坚持使用久经考验的 if 语句，或者，使用 defer 语句“声明”错误处理程序：

我认为这将属于“坚持久经考验的 if 语句”的范畴。 我希望该提案也可以改进以解决此问题。

我强烈建议 Go 团队优先考虑泛型，因为这是 Go 听到最多批评的地方，并等待错误处理。 今天的技术并不那么痛苦（尽管go fmt应该让它坐在一条线上）。

try()概念具有来自检查/句柄的check的所有问题：

1. 它不像 Go 那样读。 人们想要赋值语法，而不需要随后的 nil 测试，因为它看起来像 Go。 对检查/处理的13 个单独的答复表明了这一点； 在此处查看_Recurring Themes_：
   https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback#recurring -themes

   f, #      := os.Open(...) // return on error
   f, #panic := os.Open(...) // panic on error
   f, #hname := os.Open(...) // invoke named handler on error
   // # is any available symbol or unambiguous pair
   

2. 嵌套返回错误的函数调用会混淆操作顺序，并妨碍调试。 发生错误时的状态以及调用顺序应该很清楚，但这里不是：
   try(step4(try(step1()), try(step3(try(step2())))))
   现在回想一下语言禁止：
   f(t ? a : b)和f(a++)

3. 在没有上下文的情况下返回错误是微不足道的。 检查/处理的一个关键原理是鼓励情境化。

4. 它与类型error和最后一个返回值相关联。 如果我们需要检查其他返回值/类型的异常状态，我们回到： if errno := f(); errno != 0 { ... }

5. 它不提供多种途径。 调用存储或网络 API 的代码处理此类错误的方式不同于处理错误输入或意外内部状态的错误。 我的代码比return err更频繁地执行其中之一：

   • log.Fatal()
   • panic() 用于永远不会出现的错误
   • 记录消息并重试

@gopherbot添加 Go2，LanguageChange

如何仅使用?来解开结果，就像rust

我们对调用 try() 持怀疑态度的原因可能是两个隐式绑定。 我们看不到 try() 的返回值错误和参数的绑定。 对于 try()，我们可以制定一个规则，我们必须使用带有返回值错误的参数函数的 try()。 但是绑定到返回值不是。 所以我认为用户需要更多的表达来理解这段代码在做什么。

func doSomething() (int, %error) {
  f := try(foo())
  ...
}

• 如果 doSomething 在返回值中没有%error ，我们就不能使用 try()。
• 如果 foo() 在最后一个返回值中没有错误，我们不能使用 try()。

很难向现有语法添加新的要求/功能。

老实说，我认为 foo() 也应该有 %error。

再添加 1 条规则

• %error 在函数的返回值列表中只能是一个。

在详细的设计文档中，我注意到在早期的迭代中，建议将错误处理程序传递给 try 内置函数。 像这样：

handler := func(err error) error {
        return fmt.Errorf("foo failed: %v", err)  // wrap error
}

f := try(os.Open(filename), handler)  

甚至更好，像这样：

f := try(os.Open(filename), func(err error) error {
        return fmt.Errorf("foo failed: %v", err)  // wrap error
})  

虽然，正如文档所述，这引发了几个问题，但我认为，如果它保留了这种可能性，可以选择性地指定这样的错误处理函数或闭包，我认为这个提议会更加可取和有用。

其次，我不介意内置函数会导致函数返回，但是，对于自行车车棚来说，“try”这个名字太短了，不能暗示它会导致返回。 所以一个更长的名字，比如attempt对我来说似乎更好。

编辑：第三，理想情况下，go 语言应该首先获得泛型，其中一个重要的用例是将这个 try 函数实现为泛型的能力，因此自行车脱落可以结束，每个人都可以获得他们自己喜欢的错误处理。

黑客新闻有一定的意义： try的行为不像普通函数（它可以返回），所以给它类似函数的语法是不好的。 return或defer语法会更合适：

func CopyFile(src, dst string) (err error) {
        r := try os.Open(src)
        defer r.Close()

        w := try os.Create(dst)
        defer func() {
                w.Close()
                if err != nil {
                        os.Remove(dst) // only if a “try” fails
                }
        }()

        try io.Copy(w, r)
        try w.Close()
        return nil
}

@sheerun 对此的常见反驳是panic也是一个控制流更改内置函数。 我个人不同意，但它是正确的。

1. 与上面的@deanveloper以及其他人的类似评论相呼应，我担心我们低估了添加一个新的、有点微妙的成本，而且——尤其是在其他函数调用中内联时——管理调用堆栈控制的容易被忽视的关键字流动。 panic(...)是一个相对明确的例外（双关语不是有意的）， return是函数的唯一出路。 我认为我们不应该以它的存在为理由来添加第三个。
2. 该提案将返回一个未包装的错误规范为默认行为，并将包装错误归为您必须选择加入的东西，并带有额外的仪式。 但是，根据我的经验，这恰恰是对良好实践的倒退。 我希望这个领域的提案能够更容易，或者至少不会更难，在错误站点向错误添加上下文信息。

也许我们可以添加一个带有可选扩充功能的变体，例如tryf ，具有以下语义：

func tryf(t1 T1, t1 T2, … tn Tn, te error, fn func(error) error) (T1, T2, … Tn)

翻译这个

x1, x2, … xn = tryf(f(), func(err error) { return fmt.Errorf("foobar: %q", err) })

进入这个

t1, … tn, te := f()
if te != nil {
    if fn != nil {
        te = fn(te)
    }
    err = te
    return
}

由于这是一个明确的选择（而不是使用try ），我们可以在此设计的早期版本中找到合理的答案。 例如，如果扩充函数为 nil，则不执行任何操作，只返回原始错误。

我担心try会取代传统的错误处理，结果会使注释错误路径变得更加困难。

通过记录消息和更新遥测计数器来处理错误的代码将被期望try一切的 linter 和开发人员视为有缺陷或不正确。

a, b, err := doWork()
if err != nil {
  updateCounters()
  writeLogs()
  return err
}

Go 是一种非常社交的语言，具有由工具（fmt、lint 等）强制执行的常见习语。 请记住这个想法的社会影响 - 会有一种想要在任何地方使用它的趋势。

@politician ，抱歉，您要查找的词不是 _social_ 而是 _opinionated_。 Go 是一种自以为是的编程语言。 其余的我大多同意你的观点。

@beoran社区工具（如 Godep 和各种 linter）表明 Go 既固执己见又具有社交性，许多使用该语言的戏剧都源于这种组合。 希望我们都能同意try不应该成为下一部戏剧。

@politician感谢您的澄清，我没有那样理解。 我当然同意我们应该尽量避免戏剧化。

我对此感到困惑。

来自博客：错误是价值，从我的角度来看，它被设计为被重视而不是被忽视。

而且我确实相信 Rop Pike 所说的，“值可以被编程，因为错误就是值，所以错误可以被编程。”。

我们不应该将error视为exception ，这就像导入复杂性不仅是为了思考，也是为了编码。

“使用语言来简化你的错误处理。” ——罗布·派克

还有更多，我们可以查看这张幻灯片

我发现通过if进行错误检查特别尴尬的一种情况是关闭文件时（例如在 NFS 上）。 我想，如果.Close()可能返回错误，目前我们打算编写以下内容？

r, err := os.Open(src)
if err != nil {
    return err
}
defer func() {
    // maybe check whether a previous error occured?
    return r.Close()
}()

defer try(r.Close())能否成为一种处理此类错误的可管理语法的好方法？ 至少，以某种方式调整提案中的CopyFile()示例是有意义的，而不是忽略来自r.Close()和w.Close()的错误。

@seehuhn您的示例无法编译，因为延迟函数没有返回类型。

func doWork() (err error) {
  r, err := os.Open(src)
  if err != nil {
    return err
  }
  defer func() {
    err = r.Close()  // overwrite the return value
  }()
}

会像你期望的那样工作。 键是命名的返回值。

我喜欢这个提议，但我认为@seehuhn的例子也应该得到解决：

defer try(w.Close())

只有在尚未设置错误时才会从 Close() 返回错误。
这种模式经常被使用...

我同意有关为错误添加上下文的担忧。 我认为它是保持错误消息非常友好（和清晰）并使调试过程更容易的最佳实践之一。

我想到的第一件事是用tryf函数替换fmt.HandleErrorf $ 函数，该函数在错误前面加上额外的上下文。

func tryf(t1 T1, t1 T2, … tn Tn, te error, ts string) (T1, T2, … Tn)

例如（来自我拥有的真实代码）：

func (c *Config) Build() error {
    pkgPath, err := c.load()
    if err != nil {
        return nil, errors.WithMessage(err, "load config dir")
    }
    b := bytes.NewBuffer(nil)
    if err = templates.ExecuteTemplate(b, "main", c); err != nil {
        return nil, errors.WithMessage(err, "execute main template")
    }
    buf, err := format.Source(b.Bytes())
    if err != nil {
        return nil, errors.WithMessage(err, "format main template")
    }
    target := fmt.Sprintf("%s.go", filename(pkgPath))
    if err := ioutil.WriteFile(target, buf, 0644); err != nil {
        return nil, errors.WithMessagef(err, "write file %s", target)
    }
    // ...
}

可以改为：

func (c *Config) Build() error {
    pkgPath := tryf(c.load(), "load config dir")
    b := bytes.NewBuffer(nil)
    tryf(emplates.ExecuteTemplate(b, "main", c), "execute main template")
    buf := tryf(format.Source(b.Bytes()), "format main template")
    target := fmt.Sprintf("%s.go", filename(pkgPath))
    tryf(ioutil.WriteFile(target, buf, 0644), fmt.Sprintf("write file %s", target))
    // ...
}

或者，如果我以@agnivade为例：

func (p *pgStore) DoWork() (err error) {
    tx := tryf(p.handle.Begin(), "begin transaction")
        defer func() {
        if err != nil {
            tx.Rollback()
        }
    }()
    var res int64
    tryf(tx.QueryRow(`INSERT INTO table (...) RETURNING c1`, ...).Scan(&res), "insert table")
    _, = tryf(tx.Exec(`INSERT INTO table2 (...) VALUES ($1)`, res), "insert table2")
    return tryf(tx.Commit(), "commit transaction")
}

然而， @josharian提出了一个很好的观点，让我对这个解决方案犹豫不决：

但是，正如所写的那样，它将 fmt 样式的格式从一个包移到了语言本身，这打开了一个蠕虫罐。

我完全同意这个提议，并且可以从许多例子中看到它的好处。

我对该提案的唯一担忧是try的命名，我觉得它与其他语言的含义可能会扭曲开发者对其来自其他语言的目的的看法。 Java 来这里找。

对我来说，我更喜欢将内置函数称为pass 。 我觉得这可以更好地代表正在发生的事情。 毕竟，您没有处理错误 - 而是将其传回以由调用者处理。 try给人的印象是错误已被处理。

这对我来说是一个大拇指，主要是因为它旨在解决的问题（“典型的与错误处理相关的样板 if 语句”）对我来说根本不是问题。 如果所有错误检查都只是if err != nil { return err }那么我可以看到为此添加语法糖的一些价值（尽管 Go 是一种相对无糖的语言）。

事实上，在发生非零错误时我想要做的事情因一种情况而异。 也许我想t.Fatal(err) 。 也许我想添加一条装饰信息return fmt.Sprintf("oh no: %v", err) 。 也许我只是记录错误并继续。 也许我在我的 SafeWriter 对象上设置了一个错误标志并继续，在某些操作序列结束时检查该标志。 也许我需要采取一些其他措施。 这些都不能用try自动化。 因此，如果try的论点是它将消除所有if err != nil块，则该论点不成立。

它会消除其中的_一些_吗？ 当然。 这对我来说是一个有吸引力的提议吗？ 嗯。 我真的不担心。 对我来说， if err != nil只是 Go 的一部分，就像花括号或defer一样。 我知道对于刚接触 Go 的人来说，这看起来很冗长和重复，但由于种种原因，刚接触 Go 的人并不适合对语言进行重大更改。

传统上，对 Go 进行重大更改的标准是，提议的更改必须解决一个 (A) 重要的问题，(B) 影响很多人，并且 (C) 提议很好地解决了问题。 我不相信这三个标准中的任何一个。 我对 Go 的错误处理非常满意。

与@peterbourgon和@deanveloper 相呼应，我最喜欢Go 的一点是代码流清晰，并且panic()不像Python 中那样被视为标准流控制机制。

关于 panic 的争论，panic() 几乎总是单独出现在一条线上，因为它没有任何价值。 你不能fmt.Println(panic("oops")) 。 这极大地提高了它的知名度，使其与try()的可比性远低于人们所说的。

如果要为函数提供另一个流控制结构，我_far_ 更喜欢它是一个保证是一行中最左边的项目的语句。

提案中的一个例子为我指出了这个问题：

func printSum(a, b string) error {
        fmt.Println(
                "result:",
                try(strconv.Atoi(a)) + try(strconv.Atoi(b)),
        )
        return nil
}

控制流确实变得不那么明显并且非常模糊。

这也违背了 Rob Pike 的初衷，即所有错误都需要明确处理。

虽然对此的反应可能是“然后不要使用它”，但问题是——其他库将使用它，并且调试它们、阅读它们并使用它们变得更加成问题。 这将激励我的公司永远不要采用 go 2，并开始只使用不使用try的库。 如果我并不孤单，它可能会导致 a-la python 2/3 的分裂。

此外， try的命名将自动暗示最终catch将出现在语法中，我们将回到 Java。

因此，由于这一切，我_强烈_反对这个提议。

我不喜欢try这个名字。 它意味着_尝试_做一些失败风险很高的事情（我可能对 _try_ 有文化偏见，因为我不是以英语为母语的人），而try将用于我们预计罕见失败的情况（希望减少错误处理的冗长的动机）并且是乐观的。 此外，此提案中的try实际上_捕获_了一个错误以提前返回它。 我喜欢@HiImJC 的pass建议。

除了名称之外，我发现现在隐藏在表达式中间的类似return的语句很尴尬。 这打破了 Go flow 风格。 这将使代码审查变得更加困难。

总的来说，我发现这个提议只会让懒惰的程序员受益，他们现在拥有更短代码的武器，甚至更少的理由去包装错误。 由于它也会使审查变得更加困难（在表达式中间返回），我认为这个提议违背了 Go 的“大规模编程”目标。

我在描述 Go 语言时通常会说的关于 Go 的最喜欢的事情之一是，对于大多数事情来说，只有一种方法可以做事。 这个提议通过提供多种方法来做同样的事情，有点违背这个原则。 我个人认为这不是必需的，它会带走，而不是增加语言的简单性和可读性。

我总体上喜欢这个提议。 与defer的交互似乎足以提供一种符合人体工程学的返回错误的方式，同时还添加了额外的上下文。 尽管解决@josharian指出的关于如何在包装的错误消息中包含原始错误的问题会很好。

缺少的是与桌面上的错误检查建议交互的符合人体工程学的方式。 我认为 API 应该非常慎重地考虑它们返回的错误类型，默认值可能应该是“返回的错误无法以任何方式检查”。 然后应该很容易进入可以以精确方式检查错误的状态，如函数签名所记录的那样（“它在情况 A 中报告类型 X 的错误，在情况 B 中报告类型 Y 的错误”）。

不幸的是，到目前为止，这个提议使最符合人体工程学的选择成为最不受欢迎的（对我来说）； 盲目地通过任意错误类型。 我认为这是不可取的，因为它鼓励不要考虑您返回的错误类型以及您的 API 用户将如何使用它们。 这个提议增加的便利性当然很好，但我担心它会鼓励不良行为，因为感知到的便利性将超过仔细考虑您提供（或泄漏）哪些错误信息的感知价值。

如果try返回的错误被转换为非“不可打包”的错误，那么创可贴就是。 不幸的是，这也有相当严重的缺点，因为它使得任何defer都无法检查错误本身。 此外，它还可以防止try实际上会返回所需类型的错误（即小心使用try而不是粗心使用的用例）。

另一种解决方案是重新利用（废弃的）想法，即为try提供可选的第二个参数，用于定义/白名单可能从该站点返回的错误种类。 这有点麻烦，因为我们有两种不同的方式来定义“错误类型”，或者按值（ io.EOF等）或按类型（ *os.PathError ， *exec.ExitError ）。 指定作为函数参数的错误类型很容易，但指定类型更难。 不知道如何处理，但把这个想法扔在那里。

@josharian指出的问题可以通过延迟对 err 的评估来避免：

defer func() { fmt.HandleErrorf(&err, "oops: %v", err) }()

看起来不太好，但应该可以。 但是，如果可以通过为错误指针或一般的指针添加新的格式化动词/标志来解决此问题，我更愿意将其打印为普通%v的取消引用值。 出于示例的目的，我们称它为%*v ：

defer fmt.HandleErrorf(&err, "oops: %*v", &err)

撇开问题不谈，我认为这个提议看起来很有希望，但保持为错误添加上下文的人体工程学似乎至关重要。

编辑：

另一种方法是将错误指针包装在实现Stringer的结构中：

type wraperr struct{ err *error }
func (w wraperr) String() string { return (*w.err).Error() }

...

defer handleErrorf(&err, "oops: %v", wraperr{&err})

从我的角度来看有几件事。 为什么我们如此关心节省几行代码？ 我认为这与Small functions 被认为是有害的相同。

此外，我发现这样的提议会将正确处理错误的责任转移到一些“魔法”上，我担心这些“魔法”会被滥用，并鼓励懒惰，从而导致代码质量差和错误。

如上所述的提案也有许多不明确的行为，所以这已经比_explicit_额外的~3行更清楚了。

我们目前在内部很少使用延迟模式。 当我们写这篇文章时，这里有一篇文章也有类似的混合接收 - https://bet365techblog.com/better-error-handling-in-go

然而，我们对它的使用是为了期待check / handle提案的进展。

Check/handle 是一种更全面的方法，可以使错误处理更加简洁。 它的handle块保留了与定义它的函数范围相同的函数范围，而任何defer语句都是新的上下文，无论多少开销。 这似乎更符合 go 的习惯用法，因为如果您想要“仅在错误发生时返回错误”的行为，您可以将其明确声明为handle { return err } 。

Defer 显然也依赖于维护的 err 引用，但是我们已经看到使用块范围的 var 隐藏错误引用会出现问题。 因此，它不足以被认为是处理 go 错误的标准方法。

在这种情况下， try似乎并没有解决太多问题，我和其他人一样担心它只会导致惰性实现，或者过度使用延迟模式的实现。

如果基于延迟的错误处理将成为一件事，那么可能应该将类似这样的内容添加到错误包中：

        f := try(os.Create(filename))
        defer errors.Deferred(&err, f.Close)

忽略延迟关闭语句的错误是一个很常见的问题。 应该有一个标准工具来帮助它。

返回的内置函数比具有相同功能的关键字更难卖。
如果它是 Zig[1] 中的关键字，我会更喜欢它。

1. https://ziglang.org/documentation/master/#try

内置函数，其类型签名无法使用语言的类型系统来表达，其行为混淆了函数的正常含义，就像一个可以重复使用以避免实际语言演变的逃生舱。

我们习惯于立即识别返回语句（和恐慌），因为这就是这种控制流在 Go（和许多其他语言）中的表达方式。 在一些习惯之后，我们也将尝试识别为更改控制流，这似乎并不牵强，就像我们对返回所做的那样。 我毫不怀疑良好的 IDE 支持也会对此有所帮助。

我认为这是相当牵强的。 在 gofmt'ed 代码中，return 总是匹配/^\t*return / - 这是一个非常简单的模式，无需任何帮助即可通过肉眼发现。 另一方面， try可以出现在代码中的任何位置，可以任意嵌套在函数调用的深处。 再多的培训也不会让我们能够在没有工具帮助的情况下立即发现函数中的所有控制流。

此外，依赖于“良好的 IDE 支持”的功能在所有没有良好 IDE 支持的环境中都会处于劣势。 代码审查工具立即浮现在脑海中——Gerrit 会为我突出显示所有的尝试吗？ 出于各种原因选择不使用 IDE 或花哨的代码突出显示的人呢？ acme 会开始突出显示try吗？

语言特性本身应该很容易理解，而不是依赖于编辑器的支持。

@kungfusheep我喜欢那篇文章。 在没有try的情况下，单独处理 defer 包装已经大大提高了可读性。

我在阵营中并不认为 Go 中的错误真的是一个问题。 即便如此， if err != nil { return err }在某些功能上还是很卡顿的。 我编写了几乎在每条语句之后都需要进行错误检查的函数，除了换行和返回之外，没有其他函数需要任何特殊处理。 有时只是没有任何聪明的 Buffer 结构可以让事情变得更好。 有时这只是一个又一个不同的关键步骤，如果出现问题，您只需简单地短路即可。

尽管try在完全向后兼容的同时肯定会使代码更容易阅读，但我同意try不是关键的必备功能，所以如果人们太害怕也许最好不要拥有它。

不过，语义非常明确。 每当您看到try时，它要么遵循快乐的道路，要么返回。 我真的不能比这更简单了。

这看起来像一个特殊的大小写宏。

@dominikh try总是匹配/try\(/所以我不知道你的意思是什么。 它同样可搜索，而且我听说过的每个编辑器都有搜索功能。

@qrpnxz我认为他试图说明的重点不是你不能以编程方式搜索它，而是用你的眼睛更难搜索。 正则表达式只是一个类比，重点放在/^\t*上，表示所有返回值都位于行首（忽略前导空格）。

想多了，应该有几个常用的辅助函数。 也许它们应该放在一个名为“deferred”的包中。

使用格式解决check的建议以避免命名返回，您可以使用检查 nil 的函数来执行此操作，如下所示

func Format(err error, message string, args ...interface{}) error {
    if err == nil {
        return nil
    }
    return fmt.Errorf(...)
}

这可以在没有命名返回的情况下使用，如下所示：

func foo(s string) (int, error) {
    n, err := strconv.Atoi(s)
    try(deferred.Format(err, "bad string %q", s))
    return n, nil
}

建议的 fmt.HandleError 可以放入 deferred 包中，而我的errors.Defer 辅助函数可以称为deferred.Exec并且只有在错误为非 nil 时才能执行程序的条件 exec。

把它放在一起，你会得到类似的东西

func CopyFile(src, dst string) (err error) {
    defer deferred.Annotate(&err, "copy %s %s", src, dst)

    r := try(os.Open(src))
    defer deferred.Exec(&err, r.Close)

    w := try(os.Create(dst))
    defer deferred.Exec(&err, r.Close)

    defer deferred.Cond(&err, func(){ os.Remove(dst) })
    try(io.Copy(w, r))

    return nil
}

另一个例子：

func (p *pgStore) DoWork() (err error) {
    tx := try(p.handle.Begin())

    defer deferred.Cond(&err, func(){ tx.Rollback() })

    var res int64 
    err = tx.QueryRow(`INSERT INTO table (...) RETURNING c1`, ...).Scan(&res)
    try(deferred.Format(err, "insert table")

    _, err = tx.Exec(`INSERT INTO table2 (...) VALUES ($1)`, res)
    try(deferred.Format(err, "insert table2"))

    return tx.Commit()
}

这个提议使我们从到处都有if err != nil ，到到处都有try 。 它改变了提出的问题并且没有解决它。

虽然，我认为当前的错误处理机制从一开始就不是问题。 我们只需要改进工具并围绕它进行审查。

此外，我认为if err != nil实际上比try更具可读性，因为它不会弄乱业务逻辑语言的行，而是位于它的正下方：

file := try(os.OpenFile("thing")) // less readable than, 

file, err := os.OpenFile("thing")
if err != nil {

}

如果 Go 要在错误处理方面更加神奇，为什么不完全拥有它。 例如，如果用户没有分配错误，Go 可以隐式调用内置try 。 例如：

func getString() (string, error) { ... }

func caller() {
  defer func() {
    if err != nil { ... } // whether `err` must be defined or not is not shown in this example. 
  }

  // would call try internally, because a user is not 
  // assigning an error value. Also, it can add a compile error
  // for "defined and not used err value" if the user does not 
  // handle the error. 
  str := getString()
}

对我来说，这实际上会以魔法和潜在的可读性为代价来解决冗余问题。

因此，我建议我们要么真正解决上面示例中的“问题”，要么保留当前的错误处理，而不是改变语言来解决冗余和包装，我们不改变语言，但我们改进工具和审查代码以使体验更好。

例如，在 VSCode 中有一个名为iferr的代码段，如果您键入它并按 Enter 键，它会扩展为完整的错误处理语句……因此，写它对我来说永远不会感到厌烦，以后再读会更好.

@josharian

虽然这不是“一个适度的库更改”，但我们也可以考虑接受 func main() 错误。

问题在于，并非所有平台都对这意味着什么有明确的语义。 您的重写在运行在完整操作系统上的“传统”Go 程序中运行良好 - 但是一旦您编写微控制器固件甚至只是 WebAssembly，就不清楚os.Exit(1)的含义。 目前， os.Exit是一个库调用，所以 Go 实现是免费的，只是不提供它。 main的形状是一个语言问题。

关于提案的一个问题可能最好由“nope”回答： try如何与可变参数交互？ 这是最后一个参数中没有它的 variadic-nes 的可变参数 (ish) 函数的第一种情况。 这是否允许：

var e []error
try(e...)

撇开你为什么会这样做。 我怀疑答案是“否”（否则后续是“如果扩展切片的长度为 0 会怎样）。只是提出这个问题，以便在最终制定规范时牢记这一点。

• Go 中的几个最伟大的特性是当前的内置确保清晰的控制流，明确和鼓励错误处理，并且强烈劝阻开发人员不要编写“神奇”的代码。 try提议与这些基本原则不一致，因为它会以牺牲控制流的可读性为代价来促进速记。
• 如果这个提议被采纳，那么也许考虑使try内置语句而不是函数。 然后它与if等其他控制流语句更一致。 此外，删除嵌套括号略微提高了可读性。
• 同样，如果该提案被采纳，那么可能不使用defer或类似的方式来实施它。 它已经无法在纯 go 中实现（正如其他人所指出的那样），因此它也可以在后台使用更有效的实现。

我看到了两个问题：

1. 它将大量代码嵌套在函数中。 这增加了很多额外的认知负担，试图在你的脑海中解析代码。

1. 它为我们提供了代码可以从语句中间退出的地方。

2号我认为更糟糕。 这里的所有示例都是返回错误的简单调用，但更阴险的是：

func doit(abc string) error {
    a := fmt.Sprintf("value of something: %s\n", try(getValue(abc)))
    log.Println(a)
    return nil
}

这段代码可以在 sprintf 的中间退出，而且很容易错过这个事实。

我的投票是否定的。 这不会让 Go 代码变得更好。 它不会使它更容易阅读。 它不会使它更健壮。

我之前说过，这个提议就是例证——我觉得 90% 的关于 Go 的抱怨都是“我不想写 if 语句或循环”。 这删除了一些非常简单的 if 语句，但增加了认知负担，并且很容易错过函数的退出点。

我只想指出，你不能在 main 中使用它，它可能会让新用户或教学时感到困惑。 显然，这适用于任何不返回错误的函数，但我认为 main 是特殊的，因为它出现在许多示例中。

func main() {
    f := try(os.Open("foo.txt"))
    defer f.Close()
}

我不确定在 main 中尝试恐慌是否可以接受。

此外，它在测试（ func TestFoo(t* testing.T) ）中并不是特别有用，这很不幸:(

我遇到的问题是它假设你总是想在错误发生时返回它。 当您可能想为错误添加上下文并将其返回时，或者您可能只想在发生错误时采取不同的行为。 也许这取决于返回的错误类型。

我更喜欢类似于 try/catch 的东西，它可能看起来像

假设foo()定义为

func foo() (int, error) {}

然后你可以做

n := try(foo()) {
    case FirstError:
        // do something based on FirstError
    case OtherError:
        // do something based on OtherError
    default:
        // default behavior for any other error
}

翻译成

n, err := foo()
if errors.Is(err, FirstError) {
    // do something based on FirstError
if errors.Is(err, OtherError) {
    // do something based on OtherError
} else {
    // default behavior for any other error
}

对我来说，错误处理是代码库中最重要的部分之一。
已经有太多的 go 代码是if err != nil { return err } ，在不添加额外上下文的情况下从堆栈深处返回错误，或者甚至（可能）更糟糕地通过使用fmt.Errorf包装来掩盖底层错误来添加上下文。

提供一个新的关键字，它是一种魔法，除了替换if err != nil { return err }之外什么都不做，这似乎是一条危险的道路。
现在所有代码都将被包装在一个调用中以进行尝试。 对于仅处理包内错误的代码，这有点好（尽管可读性很差），例如：

func foo() error {
  /// stuff
  try(bar())
  // more stuff
}

但我认为给定的示例确实有点可怕，基本上让调用者试图理解堆栈中非常深的错误，就像异常处理一样。
当然，这完全取决于开发人员在这里做正确的事情，但它为开发人员提供了一种很好的方式来不关心他们的错误，也许是“我们稍后会解决这个问题”（我们都知道这是怎么回事）。

我希望我们从不同的角度来看待这个问题，而不是*“我们如何减少重复”以及“我们如何使（正确的）错误处理更简单，开发人员更有效率”。
我们应该考虑这将如何影响运行的生产代码。

*注意：这实际上并没有减少重复，只是改变了重复的内容，同时降低了代码的可读性，因为所有内容都包含在try()中。

最后一点：起初阅读提案看起来不错，然后你开始了解所有的陷阱（至少列出的那些），就像“好吧，这太多了”。

我意识到这在很大程度上是主观的，但这是我关心的事情。 这些语义非常重要。
我想看到的是一种使编写和维护生产级代码更简单的方法，这样即使对于 POC/演示级代码，您也可以“正确”地出错。

由于错误上下文似乎是一个反复出现的主题......

假设：大多数 Go 函数返回(T, error)而不是(T1, T2, T3, error)

如果不是将try定义为try(T1, T2, T3, error) (T1, T2, T3)而是将其定义为
try(func (args) (T1, T2, T3, error))(T1, T2, T3) ? （这是一个近似值）

也就是说， try调用的句法结构始终是第一个参数，它是一个返回多个值的表达式，最后一个是错误。

然后，很像make ，这为调用的 2 参数形式打开了大门，其中第二个参数是 try 的上下文（例如，固定字符串，带有%v的字符串

这仍然允许链接(T, error)案例，但您不能再链接通常不需要 IMO 的多个退货。

@cpuguy83如果您阅读该提案，您会发现没有什么可以阻止您包装错误。 事实上，在使用try的同时有多种方法可以做到这一点。 不过，许多人似乎出于某种原因认为是这样的。

if err != nil { return err }与try一样“我们稍后会解决”，只是在原型设计时更烦人。

我不知道一对括号内的东西比每四行样板文件中的函数步骤的可读性差。

如果您指出其中一些困扰您的特定“陷阱”，那就太好了，因为这就是主题。

可读性似乎是一个问题，但是 go fmt 呈现 try() 以使其脱颖而出，例如：

f := try(
    os.Open("file.txt")
)

@MrTravisB

我遇到的问题是它假设你总是想在错误发生时返回它。

我不同意。 它假设您想要这样做的频率足以保证为此使用速记。 如果你不这样做，它就不会妨碍简单地处理错误。

当您可能想为错误添加上下文并将其返回时，或者您可能只想在发生错误时采取不同的行为。

该提案描述了一种向错误添加块范围上下文的模式。 @josharian指出示例中存在错误，但目前尚不清楚避免它的最佳方法是什么。 我已经写了几个处理它的方法的例子。

同样，对于更具体的错误上下文， try会做一件事，如果您不想要那件事，请不要使用try 。

@boomlinde正是我的观点。 这个提议试图解决一个单一的用例，而不是提供一个工具来解决更大的错误处理问题。 我认为基本问题是否正是您所指出的。

它假设您想要这样做的频率足以保证为此使用速记。

根据我的观点和经验，这个用例是少数，不保证速记语法。

此外，使用defer处理错误的方法存在问题，因为它假设您希望以相同的方式处理所有可能的错误。 defer语句无法取消。

defer fmt.HandleErrorf(&err, “foobar”)

n := try(foo())

x : try(foo2())

如果我想要对可能从foo()与foo2()返回的错误进行不同的错误处理怎么办？

@MrTravisB

如果我想要对可能从 foo() 和 foo2() 返回的错误进行不同的错误处理怎么办？

然后你用别的东西。 这就是@boomlinde的目的。

也许您个人并不经常看到这个用例，但很多人会看到，并且添加try并不会真正影响您。 事实上，用例对您来说越少，添加try对您的影响就越小。

@qrpnxz

f := try(os.Open("/foo"))
data := try(ioutil.ReadAll(f))
try(send(data))

（是的，我知道有ReadFile并且这个特定的示例不是在某处复制数据的最佳方式，而不是重点）

这需要花费更多的精力来阅读，因为您必须解析出 try 的内联。 应用程序逻辑包含在另一个调用中。
我还争辩说，这里的defer错误处理程序并不好，只是用一条新消息包装错误......这很好，但处理错误比让处理更容易人类阅读发生了什么。

在 rust 中，至少操作符是一个后缀（ ?添加到调用末尾），它不会增加挖掘实际逻辑的额外负担。

基于表达式的流控制

panic可能是另一个流控制函数，但它不返回值，因此它实际上是一个语句。 将此与try进行比较，后者是一个表达式，可以出现在任何地方。

recover确实有一个值并影响流控制，但必须出现在defer语句中。 这些defer通常是函数文字， recover只被调用一次，因此recover也有效地作为语句出现。 同样，将此与可以在任何地方发生的try进行比较。

我认为这些观点意味着try使得以我们以前没有过的方式遵循控制流变得更加困难，正如之前所指出的，但我没有看到语句和表达式之间的区别指出。

另一个提议

允许这样的语句

if err != nil {
    return nil, 0, err
}

当块仅包含return语句并且该语句不包含换行符时，将在一行上格式化gofmt 。 例如：

if err != nil { return nil, 0, err }

基本原理

• 它不需要更改语言
• 格式化规则简单明了
• 该规则可以设计为选择在gofmt保留换行符的位置（如果它们已经存在）（如结构文字）。 选择加入还允许作者强调一些错误处理
• 如果不选择加入，代码可以通过调用gofmt自动移植到新样式
• 它仅适用于return语句，因此不会被不必要地滥用到高尔夫球代码中
• 与描述为什么会发生一些错误以及为什么它们被返回的评论很好地交互。 使用许多嵌套的try表达式处理得不好
• 它将错误处理的垂直空间减少了 66%
• 没有基于表达式的控制流
• 阅读代码的频率远高于编写代码的频率，因此应该针对读者进行优化。 占用较少空间的重复代码对读者有帮助，其中try更倾向于作者
• 人们已经提议在多条线路上存在try 。 例如这条评论或这条评论引入了类似的风格

f, err := os.Open(file)
try(maybeWrap(err))

• “try on its own line”样式消除了关于返回的err值的任何歧义。 因此，我怀疑这种形式会被普遍使用。 允许一个内衬 if 块几乎是一回事，除了它也明确了返回值是什么
• 它不提倡使用命名返回或不明确的基于defer的包装。 两者都增加了包装错误的障碍，前者可能需要godoc更改
• 无需讨论何时使用try与使用传统错误处理
• 不排除将来做try或其他事情。 即使try被接受，变化也可能是积极的
• 与testing库或main函数没有负面交互。 事实上，如果提案允许任何单行语句而不是仅仅返回，它可能会减少基于断言的库的使用。 考虑

value, err := something()
if err != nil { t.Fatal(err) }

• 与检查特定错误没有负面互动。 考虑

n, err := src.Read(buf)
if err == io.EOF { return nil }
else if err != nil { return err }

总而言之，这个提议成本低，可以设计为可选，不排除任何进一步的变化，因为它只是风格，并且减少了阅读冗长的错误处理代码的痛苦，同时保持一切明确。 我认为在全力以赴之前，至少应该将其视为第一步try 。

来自https://github.com/golang/go/issues/32437#issuecomment -498941435

尝试

func NewThing(thingy *foo.Thingy, db *sql.DB, client pb.Client) (*Thing, error) {
        try(dbfile.RunMigrations(db, dbMigrations))
        t := &Thing{
                thingy:  thingy,
                scanner: try(newScanner(thingy, db, client)),
        }
        t.initOtherThing()
        return t, nil
}

有了这个

func NewThing(thingy *foo.Thingy, db *sql.DB, client pb.Client) (*Thing, error) {
        err := dbfile.RunMigrations(db, dbMigrations))
        if err != nil { return nil, fmt.Errorf("running migrations: %v", err) }

        t := &Thing{thingy: thingy}
        t.scanner, err = newScanner(thingy, db, client)
        if err != nil { return nil, fmt.Errorf("creating scanner: %v", err) }

        t.initOtherThing()
        return t, nil
}

它在空间使用方面具有竞争力，同时仍允许为错误添加上下文。

来自https://github.com/golang/go/issues/32437#issuecomment -499007288

尝试

func (c *Config) Build() error {
    pkgPath := try(c.load())
    b := bytes.NewBuffer(nil)
    try(emplates.ExecuteTemplate(b, "main", c))
    buf := try(format.Source(b.Bytes()))
    target := fmt.Sprintf("%s.go", filename(pkgPath))
    try(ioutil.WriteFile(target, buf, 0644))
    // ...
}

有了这个

func (c *Config) Build() error {
    pkgPath, err := c.load()
    if err != nil { return nil, errors.WithMessage(err, "load config dir") }

    b := bytes.NewBuffer(nil)
    err = templates.ExecuteTemplate(b, "main", c)
    if err != nil { return nil, errors.WithMessage(err, "execute main template") }

    buf, err := format.Source(b.Bytes())
    if err != nil { return nil, errors.WithMessage(err, "format main template") }

    target := fmt.Sprintf("%s.go", filename(pkgPath))
    err = ioutil.WriteFile(target, buf, 0644)
    if err != nil { return nil, errors.WithMessagef(err, "write file %s", target) }
    // ...
}

原始评论使用假设的tryf来附加格式，该格式已被删除。 目前还不清楚添加所有不同上下文的最佳方法，也许try甚至都不适用。

@cpuguy83
对我来说，使用try更具可读性。 在这个例子中，我读到“打开一个文件，读取所有字节，发送数据”。 通过常规错误处理，我会阅读“打开文件，检查是否有错误，错误处理会执行此操作，然后读取所有字节，现在检查是否发生了某些事情......”我知道你可以扫描err != nil s，但对我来说try更容易，因为当我看到它时，我立即知道行为：如果 err != nil 则返回。 如果你有一个分支，我必须看看它的作用。 它可以做任何事情。

我还认为，这里的延迟错误处理程序并不好，只是用新消息包装错误

我确定您可以在延迟中做其他事情，但无论如何， try无论如何都是针对简单的一般情况的。 任何时候你想做更多的事情，总是有好的 ol' Go 错误处理。 那不会消失。

@zeebo是的，我很喜欢。
@kungfusheep的文章使用了这样的单行错误检查，我退出尝试。 然后，我一保存，gofmt 就将其扩展为三行，这很可悲。 stdlib 中的许多函数都是这样定义在一行中的，所以 gofmt 会扩展它让我感到惊讶。

@qrpnxz

我碰巧读了很多go 代码。 该语言最好的事情之一是大多数代码遵循特定风格（感谢 gofmt）带来的易用性。
我不想阅读包装在try(f())中的一堆代码。
这意味着代码风格/实践会出现分歧，或者像“哦，你应该在这里使用try() ”这样的短句（我也不喜欢，这是我和其他人评论的重点关于这个提议）。

客观上它并不比if err != nil { return err }好，只是打字少。

最后一件事：

如果您阅读该提案，您会发现没有什么可以阻止您

我们可以不要使用这种语言吗？ 当然，我阅读了提案。 碰巧我昨晚读了它，然后在今天早上思考后发表了评论，并没有解释我想要表达的细节。
这是一种令人难以置信的敌对语气。

@cpuguy83
我的坏cpu家伙。 我不是那个意思。

而且我想你必须指出使用try的代码看起来与不使用的代码完全不同，所以我可以想象这会影响解析该代码的体验，但我不能完全同意不同在这种情况下意味着更糟，尽管我知道你个人不喜欢它，就像我个人喜欢它一样。 Go 中的很多东西都是这样的。 至于 linter 告诉你做什么完全是另一回事，我认为。

当然，客观上并没有更好。 我表示这样对我来说更具可读性。 我小心翼翼地这么说。

再次，抱歉听起来那样。 虽然这是一个论点，但我并不是要对抗你。

https://github.com/golang/go/issues/32437#issuecomment -498908380

没有人会让你尝试使用。

忽略油嘴滑舌，我认为这是一种非常随意的方式来驳斥设计批评。

当然，我不必使用它。 但是任何与我一起编写代码的人都可以使用它并强迫我尝试破译try(try(try(to()).parse().this)).easily()) 。 这就像说

没有人会让你使用空接口{}。

无论如何，Go 对简单性非常严格： gofmt使所有代码看起来都一样。 幸福的道路向左走，任何可能昂贵或令人惊讶的事情都是明确的。 所提议的try是一个180 度的转弯。 简单！=简洁。

至少try应该是带有左值的关键字。

它_objectively_并不比if err != nil { return err }好，只是打字少。

两者之间有一个客观区别： try(Foo())是一个表达式。 对于某些人来说，这种差异是不利的（ try(strconv.Atoi(x))+try(strconv.Atoi(y))批评）。 对于其他人来说，出于同样的原因，这种差异是一个好处。 仍然没有客观上更好或更坏 - 但我也不认为应该将差异扫在地毯下，并声称它“只是少打字”并不能使提案公正。

@elagergren-spideroak 很难说try一口气看到很烦人，然后说接下来就不明确了。 你得选一个。

通常会看到函数参数首先放入临时变量中。 我相信它会更常见

this := try(to()).parse().this
that := try(this.easily())

比你的例子。

try什么都不做是幸福的道路，所以看起来和预期的一样。 在不愉快的道路上，它所做的只是返回。 看到有try就足以收集该信息。 从函数返回也没有什么昂贵的，所以从那个描述我不认为try正在做 180

@josharian关于您在https://github.com/golang/go/issues/32437#issuecomment -498941854 中的评论，我认为这里没有早期评估错误。

defer fmt.HandleErrorf(&err, “foobar: %v”, err)

err的未修改值传递给HandleErrorf ，并传递指向err的指针。 我们检查err是否为nil （使用指针）。 如果不是，我们使用err的未修改值格式化字符串。 然后我们使用指针将err设置为格式化的错误值。

@Merovius该提案实际上只是一个语法糖宏，所以它最终会成为人们认为看起来更好或会造成最少麻烦的东西。 如果您不认为，请向我解释。 这就是我个人支持它的原因。 从我的角度来看，这是一个很好的补充，无需添加任何关键字。

@ianlancetaylor ，我认为@josharian是正确的： err的“未修改”值是defer被推入堆栈时的值，而不是err的（可能是预期的）值try $ 设置。

我对try的另一个问题是，它使人们更容易将更多和逻辑转储到一行中。 这是我对大多数其他语言的主要问题，它们使将 5 个表达式放在一行中变得非常容易，而且我不希望这样。

this := try(to()).parse().this
that := try(this.easily())

^^ 即使这也非常糟糕。 第一行，我必须在脑海中来回跳来做paren匹配。 即使是实际上非常简单的第二行......也很难阅读。
嵌套函数很难阅读。

parser, err := to()
if err != nil {
    return err
}
this := parser.parse().this
that, err := this.easily()
if err != nil {
    return err
}

^^ 这比 IMO 更容易和更好。 它超级简单明了。 是的，这是更多的代码行，我不在乎。 这很明显。

@bcmills @josharian啊，当然，谢谢。 所以它必须是

defer func() { fmt.HandleErrorf(&err, “foobar: %v”, err) }()

不太好。 也许fmt.HandleErrorf毕竟应该隐式地将错误值作为最后一个参数传递。

这个问题很快就得到了很多评论，在我看来，他们中的许多人似乎在重复已经发表的评论。 当然，请随意发表评论，但我想温和地建议，如果您想重申已经提出的观点，请使用 GitHub 的表情符号来做到这一点，而不是重复这一点。 谢谢。

@ianlancetaylor如果fmt.HandleErrorf发送 err 作为 format 之后的第一个参数，那么实现会更好，用户将能够始终通过%[1]v引用它。

@natefinch完全同意。

我想知道生锈风格的方法是否更可口？
请注意，这不是一个只是考虑一下的提议......

this := to()?.parse().this
that := this.easily()?

最后我认为这更好，但是（也可以使用!或其他东西......），但仍然不能很好地解决处理错误的问题。

当然 rust 也有try()几乎就像这样，但是......另一种 rust 风格。

它_objectively_并不比if err != nil { return err }好，只是打字少。

两者之间有一个客观区别： try(Foo())是一个表达式。 对于某些人来说，这种差异是不利的（ try(strconv.Atoi(x))+try(strconv.Atoi(y))批评）。 对于其他人来说，出于同样的原因，这种差异是一个好处。 仍然没有客观上更好或更坏 - 但我也不认为应该将差异扫在地毯下，并声称它“只是少打字”并不能使提案公正。

这是我喜欢这种语法的最大原因之一； 它让我可以将错误返回函数用作更大表达式的一部分，而无需命名所有中间结果。 在某些情况下命名它们很容易，但在其他情况下，没有特别有意义或非冗余的名称可以给它们，在这种情况下，我宁愿根本不给它们命名。

@MrTravisB

正是我的观点。 这个提议试图解决一个单一的用例，而不是提供一个工具来解决更大的错误处理问题。 我认为基本问题是否正是您所指出的。

我具体说了什么，这正是你的意思？ 在我看来，如果您认为我们同意，您从根本上误解了我的观点。

根据我的观点和经验，这个用例是少数，不保证速记语法。

在 Go 源代码中，即使无法为错误添加上下文，也有成千上万的案例可以由try开箱即用地处理。 如果轻微，它仍然是投诉的常见原因。

此外，使用 defer 处理错误的方法存在问题，因为它假定您希望以相同的方式处理所有可能的错误。 defer 语句不能被取消。

类似地，使用 + 处理算术的方法假设您不想减法，所以如果您不想减法，您就不要减法。 有趣的问题是块范围的错误上下文是否至少代表了一种常见的模式。

如果我想要对可能从 foo() 与 foo2() 返回的错误进行不同的错误处理怎么办

同样，您不要使用try 。 然后，您不会从try中获得任何收益，但您也不会失去任何东西。

@cpuguy83

我想知道生锈风格的方法是否更可口？

该提案提出了反对这一点的论据。

在这一点上，我认为try{}catch{}更具可读性：upside_down_face：

1. 使用命名导入来绕过defer极端情况不仅对于像 godoc 这样的东西来说很糟糕，而且最重要的是它很容易出错。 我不在乎我可以用另一个func()来解决这个问题，这只是我需要记住的更多事情，我认为它会鼓励“不良做法”。

2. 没有人会让你尝试使用。

   这并不意味着它是一个好的解决方案，我要指出当前的想法在设计中存在缺陷，我要求以一种不易出错的方式解决它。

3. 我认为像try(try(try(to()).parse().this)).easily())这样的例子是不切实际的，这已经可以用其他函数来完成，我认为那些审查代码的人要求将其拆分是公平的。

4. 如果我有 3 个可能出错的地方并且我想分别包装每个地方怎么办？ try()让这变得非常困难，事实上try()考虑到它的难度已经在阻止包装错误，但这里有一个例子说明我的意思：

   func before() error {
     x, err := foo()
     if err != nil {
       wrap(err, "error on foo")
     }
     y, err := bar(x)
     if err != nil {
       wrapf(err, "error on bar with x=%v", x)
     }
     fmt.Println(y)
     return nil
   }
   
   func after() (err error) {
     defer fmt.HandleErrorf(&err, "something failed but I don't know where: %v", err)
     x := try(foo())
     y := try(bar(x))
     fmt.Println(y)
     return nil
   }
   

5. 同样，您不要使用try 。 然后，您不会从try中获得任何收益，但您也不会失去任何东西。

   假设用有用的上下文包装错误是一种很好的做法， try()将被认为是一种不好的做法，因为它没有添加任何上下文。 这意味着try()是一个没人愿意使用的功能，并成为一个很少使用的功能，以至于它可能不存在。

   与其只是说“好吧，如果你不喜欢它，不要使用它并闭嘴”（这就是它的阅读方式），我认为最好尝试解决许多用户正在考虑的缺陷在设计中。 我们可以讨论一下可以从提议的设计中修改哪些内容，以便以更好的方式处理我们的问题吗？

@boomlinde我们同意的一点是，这个提议试图解决一个小用例，而“如果你不需要，就不要使用它”这一事实是它进一步推动这一点的主要论点。 正如@elagergren-spideroak 所说，这个论点是行不通的，因为即使我不想使用它，其他人也会迫使我使用它。 根据你的论点的逻辑，Go 也应该有一个三元语句。 如果您不喜欢三元语句，请不要使用它们。

免责声明 - 我确实认为 Go 应该有一个三元声明，但考虑到 Go 语言特性的方法是不引入可能使代码更难阅读的特性，而不是它不应该引入的特性。

另一件事发生在我身上：我看到很多批评基于这样的想法，即拥有try可能会鼓励开发人员粗心地处理错误。 但在我看来，如果有的话，这更适用于当前的语言。 错误处理样板文件很烦人，它鼓励人们吞下或忽略一些错误来避免它。 例如，我写过几次这样的东西：

func exists(filename string) bool {
  _, err := os.Stat(filename)
  return err == nil
}

为了能够编写if exists(...) { ... } ，即使此代码默默地忽略了一些可能的错误。 如果我有try ，我可能不会费心去做，只是返回(bool, error) 。

在这里混乱，我将提出添加第二个名为catch的内置函数的想法，它将接收一个接受错误并返回覆盖错误的函数，然后如果后续的catch调用它会覆盖处理程序。 例如：

func catch(handler func(err error) error) {
  // .. impl ..
}

现在，这个内置函数也将是一个类似宏的函数，它将处理try返回的下一个错误，如下所示：

func wrapf(format string, ...values interface{}) func(err error) error {
  // user defined
  return func(err error) error {
    return fmt.Errorf(format + ": %v", ...append(values, err))
  }
}
func sample() {
  catch(wrapf("something failed in foo"))
  try(foo()) // "something failed in foo: <error>"
  x := try(foo2()) // "something failed in foo: <error>"
  // Subsequent calls for catch overwrite the handler
  catch(wrapf("something failed in bar with x=%v", x))
  try(bar(x)) // "something failed in bar with x=-1: <error>"
}

这很好，因为我可以在没有defer的情况下包装错误，这很容易出错，除非我们使用命名返回值或用另一个 func 包装，这也很好，因为defer会添加相同的错误处理程序即使我想以不同的方式处理其中两个错误，也会出现所有错误。 您也可以根据需要使用它，例如：

func foo(a, b string) (int64, error) {
  return try(strconv.Atoi(a)) + try(strconv.Atoi(b))
}
func withContext(a, b string) (int64, error) {
  catch(func (err error) error {
    return fmt.Errorf("can't parse a: %s, b: %s, err: %v", a, b, err)
  })
  return try(strconv.Atoi(a)) + try(strconv.Atoi(b))
}
func moreExplicitContext(a, b string) (int64, error) {
  catch(func (err error) error {
    return fmt.Errorf("can't parse a: %s, err: %v", a, err)
  })
  x := try(strconv.Atoi(a))
  catch(func (err error) error {
    return fmt.Errorf("can't parse b: %s, err: %v", b, err)
  })
  y := try(strconv.Atoi(b))
  return x + y
}
func withHelperWrapf(a, b string) (int64, error) {
  catch(wrapf("can't parse a: %s", a))
  x := try(strconv.Atoi(a))
  catch(wrapf("can't parse b: %s", b))
  y := try(strconv.Atoi(b))
  return x + y
}
func before(a, b string) (int64, error) {
  x, err := strconv.Atoi(a)
  if err != nil {
    return 0,  fmt.Errorf("can't parse a: %s, err: %v", a, err)
  }
  y, err := strconv.Atoi(b)
  if err != nil {
    return 0,  fmt.Errorf("can't parse b: %s, err: %v", b, err)
  }
  return x + y
}

并且仍然处于混乱的情绪中（以帮助您同情）如果您不喜欢catch ，则不必使用它。

现在......我并不是说最后一句话，但它确实感觉它对讨论没有帮助，非常激进的IMO。
不过，如果我们走这条路，我认为我们不妨改用try{}catch(error err){} :stuck_out_tongue:

另请参阅 #27519 - #id/catch 错误模型

没有人会让你尝试使用。

忽略油嘴滑舌，我认为这是一种非常随意的方式来驳斥设计批评。

抱歉，油嘴滑舌不是我的本意。

我想说的是， try并不是一个 100% 的解决方案。 try无法很好地处理各种错误处理范例。 例如，如果您需要将调用站点相关的上下文添加到错误中。 你总是可以回退到使用if err != nil {来处理那些更复杂的情况。

对于 X 的各种实例， try不能处理 X 无疑是一个有效的论点。但通常处理案例 X 意味着使机制更加复杂。 这里有一个权衡，一方面处理 X，但使其他一切的机制复杂化。 我们所做的一切都取决于 X 有多常见，以及处理 X 需要多少复杂性。

所以“没有人会让你使用 try”，我的意思是我认为有问题的例子是 10%，而不是 90%。 这种说法肯定有待商榷，我很高兴听到反驳。 但最终我们将不得不在某处划清界限并说“是的， try不会处理这种情况。你必须使用旧式错误处理。对不起。”。

问题不是“尝试无法处理这种特定的错误处理情况”，而是“尝试鼓励您不要包装错误”。 check-handle的想法迫使您编写返回语句，因此编写错误包装非常简单。

在这个提议下，您需要使用带有defer的命名返回，这不直观而且看起来很 hacky。

check-handle的想法迫使您编写返回语句，因此编写错误包装非常简单。

这不是真的 - 在设计草案中，每个返回错误的函数都有一个默认处理程序，它只返回错误。

基于@Goodwine的顽皮点，如果你有一个单一的桥接函数，你真的不需要像HandleErrorf这样的单独函数

func handler(err *error, handle func(error) error) {
  // nil handle is treated as the identity
  if *err != nil && handle != nil {
    *err = handle(*err)
  }
}

你会用

defer handler(&err, func(err error) error {
  if errors.Is(err, io.EOF) {
    return nil
  }
  return fmt.Errorf("oops: %w", err)
})

您可以使handler本身成为像try这样的半魔法内置函数。

如果它很神奇，它可以隐式地接受它的第一个参数——即使在没有命名它们的error回报的函数中也可以使用它，淘汰当前提案中不太幸运的一个方面，同时减少它挑剔和错误容易出现装饰错误。 当然，这并不能大大减少前面的示例：

defer handler(func(err error) error {
  if errors.Is(err, io.EOF) {
    return nil
  }
  return fmt.Errorf("oops: %w", err)
})

如果它以这种方式很神奇，那么如果它在任何地方使用，除了作为defer的参数之外，它必须是一个编译时错误。 你可以更进一步，让它隐式延迟，但是defer handler读起来非常好。

由于它使用defer它可以在返回非零错误时调用其handle函数，即使没有try也可以使用它，因为您可以添加

defer handler(wrapErrWithPackageName)

在顶部到fmt.Errorf("mypkg: %w", err)一切。

这为您提供了很多较旧的check / handle提案，但它自然地（并且明确地）与 defer 一起工作，同时在大多数情况下摆脱了显式命名err的需要try一样，它是一个相对简单的宏，（我想）可以完全在前端实现。

这不是真的 - 在设计草案中，每个返回错误的函数都有一个默认处理程序，它只返回错误。

我的错，你是对的。

我的意思是我认为有问题的例子是 10%，而不是 90%。 这种说法肯定有待商榷，我很高兴听到反驳。 但最终我们将不得不在某处划清界限并说“是的，try 不会处理这种情况。你将不得不使用旧式错误处理。对不起。”。

同意，我的观点是，在检查 EOF 或类似内容时应该画这条线，而不是在包装时画。 但也许如果错误有更多的上下文，这将不再是一个问题。

try()可以用有用的上下文自动包装错误以进行调试吗？ 例如，如果xerrors变成errors ，错误应该有一个看起来像try()可以添加的堆栈跟踪的东西，不是吗？ 如果是这样也许就足够了🤔

如果目标是（阅读 https://github.com/golang/proposal/blob/master/design/32437-try-builtin.md）：

• 消除样板
• 最小的语言变化
• 涵盖“最常见的场景”
• 给语言增加很少的复杂性

我会接受这个建议，给它一个角度，并允许对所有数十亿行代码进行“小步骤”代码迁移。

而不是建议的：

func printSum(a, b string) error {
        defer fmt.HandleErrorf(&err, "sum %s %s: %v", a,b, err) 
        x := try(strconv.Atoi(a))
        y := try(strconv.Atoi(b))
        fmt.Println("result:", x + y)
        return nil
}

我们可以：

func printSum(a, b string) error {
        var err ErrHandler{HandleFunc : twoStringsErr("printSum",a,b)} 
        x, err.Error := strconv.Atoi(a)
        y,err.Error := strconv.Atoi(b)
        fmt.Println("result:", x + y)
        return nil
}

我们会得到什么？
twoStringsErr 可以内联到 printSum，或知道如何捕获错误的通用处理程序（在本例中使用 2 个字符串参数） - 所以如果我在许多函数中使用相同的重复 func 签名，我不需要重写每个处理程序时间
以同样的方式，我可以通过以下方式扩展 ErrHandler 类型：

type ioErrHandler ErrHandler
func (i ErrHandler) Handle() ...{

}

要么

type parseErrHandler ErrHandler
func (p parseErrHandler) Handle() ...{

}

要么

type str2IntErrHandler ErrHandler
func (s str2IntErrHandler) Handle() ...{

}

并在我的代码周围使用它：

func printSum(a, b string) error {
        var pErr str2IntErrHandler 
        x, err.Error := strconv.Atoi(a)
        y,err.Error := strconv.Atoi(b)
        fmt.Println("result:", x + y)
        return nil
}

因此，实际需要是在 err.Error 设置为 not nil 时开发一个触发器
使用这种方法，我们还可以：

func (s str2IntErrHandler) Handle() bool{
   **return false**
}

这会告诉调用函数继续而不是返回

并在同一函数中使用不同的错误处理程序：

func printSum(a, b string) error {
        var pErr str2IntErrHandler 
        var oErr overflowError 
        x, err.Error := strconv.Atoi(a)
        y,err.Error := strconv.Atoi(b)
        fmt.Println("result:", x + y)
        totalAsByte,oErr := sumBytes(x,y)
        sunAsByte,oErr := subtractBytes(x,y)
        return nil
}

等等。

再次超越目标

• 消除样板 - 完成
• 最少的语言更改 - 完成
• 涵盖“最常见的情况” - 超过建议的 IMO
• 给语言增加很少的复杂性 - sone
  另外 - 更容易的代码迁移

x, err := strconv.Atoi(a)

到

x, err.Error := strconv.Atoi(a)

实际上 - 更好的可读性（IMO，再次）

@guybrand你是这个反复出现的主题的最新追随者（我喜欢）。

见https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback#recurring -themes

@guybrand这似乎是一个完全不同的提议； 我认为您应该将其作为自己的问题提交，以便该问题可以专注于讨论@griesemer的提案。

@natefinch同意。 我认为这更适合在编写 Go 时改善体验，而不是针对阅读进行优化。 我想知道 IDE 宏或片段是否可以在不成为语言功能的情况下解决这个问题。

@古德温

假设用有用的上下文包装错误是一种很好的做法， try()将被认为是一种不好的做法，因为它没有添加任何上下文。 这意味着try()是一个没人愿意使用的功能，并成为一个很少使用的功能，以至于它可能不存在。

如提案中所述（并通过示例显示）， try不会从根本上阻止您添加上下文。 我想说的是，它提出的方式，为错误添加上下文是完全正交的。 提案的常见问题解答中专门解决了这一问题。

我认识到try将没有用。 但是，我也相信HandleErrorf的一般内容涵盖了很大的使用范围，因为仅向错误添加函数范围的上下文并不罕见。

与其只是说“好吧，如果你不喜欢它，不要使用它并闭嘴”（这就是它的阅读方式），我认为最好尝试解决许多用户正在考虑的缺陷在设计中。

如果是这样的话，我很抱歉。 我的意思不是说如果你不喜欢它就应该假装它不存在。 很明显，在某些情况下try将毫无用处，并且您不应该在这种情况下使用它，对于这个提议，我认为这在 KISS 和通用实用程序之间取得了很好的平衡。 我不认为我在这一点上不清楚。

感谢大家迄今为止的多产反馈； 这是非常有用的。
这是我对初步总结的尝试，以便更好地了解反馈。 为我错过或误传的任何人提前道歉； 我希望我理解了它的整体要点。

0) 在积极的一面， @rasky 、 @adg 、 @eandre 、@ dpinela和其他人明确表示对try提供的代码简化感到高兴。

1) 最重要的问题似乎是try不鼓励良好的错误处理风格，而是促进“快速退出”。 （@ agnivade 、@ peterbourgon 、@politician、@ a8m 、 @eandre 、 @ prologic 、@ kungfusheep 、@ cpuguy和其他人对此表示担忧。）

2) 许多人不喜欢内置的想法，或者它附带的函数语法，因为它隐藏了return 。 最好使用关键字。 （@ sheerun 、 @Redundancy 、@ dolmen、@komuw、@RobertGrantEllis 、 @ elagergren-spideroak）。 try也可能很容易被忽略（@peterbourgon），特别是因为它可以出现在可能任意嵌套的表达式中。 @natefinch担心try使得“在一行中倾倒太多东西太容易了”，这是我们在 Go 中通常会尽量避免的事情。 此外，强调try的 IDE 支持可能还不够（@dominikh）； try需要“独立存在”。

3) 对于某些人来说，显式if语句的现状不是问题，他们对此很满意（@bitfield、@ marwan -at-work、@natefinch）。 最好只有一种方式做事（@gbbr）； 和显式if语句优于隐式return （ @DavexPro 、 @hmage 、 @prologic 、@natefinch）。
同样， @mattn担心错误结果与try的“隐式绑定”——该连接在代码中不显式可见。

4) 使用try会使调试代码变得更加困难； 例如，可能需要将try表达式重写回if语句，以便可以插入调试语句（ @deanveloper 、 @typeless 、 @networkimprov等）。

5) 使用命名返回 ( @buchanae , @adg) 存在一些问题。

有几个人提供了改进或修改提案的建议：

6) 有些人接受了可选错误处理程序 (@beoran) 或提供给try (@ unexge 、 @a8m 、@ eandre 、@gotwarlost) 的格式字符串的想法，以鼓励良好的错误处理。

7) @pierrec建议gofmt可以适当地格式化try表达式以使它们更加可见。
或者，可以通过允许gofmt格式化if语句检查一行上的错误（@zeebo）来使现有代码更紧凑。

8) @marwan-at-work 认为try只是将错误处理从if语句转移到try表达式。 相反，如果我们想真正解决问题，Go 应该通过使其真正隐式来“拥有”错误处理。 目标应该是使（正确的）错误处理更简单，开发人员更有效率（@cpuguy）。

9) 最后，有些人不喜欢try $（@ beoran 、@ HiImJC 、@dolmen）这个名字，或者更喜欢? （ @twisted1919 、@ leaxoy等）这样的符号.

对此反馈的一些评论（相应编号）：

0) 感谢您的积极反馈！ :-)

1）了解更多有关此问题的信息会很好。 当前使用if语句来测试错误的编码风格几乎是尽可能明确的。 逐个（针对每个if ）向错误添加附加信息非常容易。 通常，以统一的方式处理函数中检测到的所有错误是有意义的，这可以通过defer来完成——这现在已经成为可能。 事实上，我们已经拥有了语言中用于良好错误处理的所有工具，以及处理程序构造与defer不正交的问题，这导致我们放弃了一种仅用于增加错误的新机制.

2）当然可以使用关键字或特殊语法代替内置语法。 新关键字不会向后兼容。 一个新的运营商可能会，但似乎更不明显。 详细的提案详细讨论了各种利弊。 但也许我们误判了这一点。

3) 这个提议的原因是错误处理（特别是相关的样板代码）被 Go 社区提到为 Go 中的一个重要问题（仅次于缺乏泛型）。 该提案直接解决了样板问题。 它只解决了最基本的案例，因为任何更复杂的案例都可以更好地处理我们已有的案例。 因此，虽然很多人对现状感到满意，但也有（可能）同样庞大的人会喜欢更简化的方法，例如try ，他们知道这是“公正的”语法糖。

4）调试点是一个有效的关注点。 如果需要在检测错误和return之间添加代码，则必须将try表达式重写为if语句可能会很烦人。

5) 命名返回值：详细文档详细讨论了这一点。 如果这是对该提案的主要关注点，那么我认为我们处于一个很好的位置。

6) try的可选处理程序参数：详细文档也讨论了这一点。 请参阅设计迭代部分。

7) 使用gofmt格式化try表达式，使它们更加可见当然是一种选择。 但是在表达式中使用它会失去try的一些好处。

8) 我们考虑从错误处理 ( handle ) 的角度而不是从错误测试 ( try ) 的角度来看问题。 具体来说，我们简要地考虑了只引入错误处理程序的概念（类似于去年 Gophercon 上提出的原始设计草案）。 当时的想法是，如果（且仅当）声明了一个处理程序，在最后一个值为error类型的多值赋值中，该值可以简单地留在赋值中。 编译器将隐式检查它是否为非零，如果是则分支到处理程序。 这将使显式错误处理完全消失，并鼓励每个人改为编写处理程序。 这似乎是一种极端的方法，因为它完全是隐含的——检查发生的事实是不可见的。

9）我可以建议我们现在不要骑自行车这个名字。 一旦所有其他问题得到解决，就是微调名称的更好时机。

这并不是说这些担忧是无效的——上面的回复只是陈述了我们目前的想法。 展望未来，最好对新的担忧（或支持这些担忧的新证据）发表评论——只是重申已经说过的话并不能为我们提供更多信息。

最后，似乎不是每个评论这个问题的人都阅读了详细的文档。 请在评论之前这样做，以避免重复已经说过的话。 谢谢。

这不是对提案的评论，而是错字报告。 自从完整的提案发布以来，它还没有修复，所以我想我会提到它：

func try(t1 T1, t1 T2, … tn Tn, te error) (T1, T2, … Tn)

应该：

func try(t1 T1, t2 T2, … tn Tn, te error) (T1, T2, … Tn)

是否值得为错误检查语句分析公开可用的 Go 代码，以尝试找出大多数错误检查是否真正重复，或者在大多数情况下，同一函数中的多个检查是否会添加不同的上下文信息？ 该提议对前一种情况很有意义，但对后者无济于事。 在后一种情况下，人们要么继续使用if err != nil ，要么放弃添加额外的上下文，使用try()并诉诸于为每个函数添加常见的错误上下文，这对 IMO 是有害的。 随着即将推出的错误值功能，我认为我们希望人们更频繁地用更多信息包装错误。 可能我误解了这个提议，但是 AFAIU，这有助于减少样板文件，只有当来自单个函数的所有错误必须以完全一种方式包装并且如果一个函数处理可能需要以不同方式包装的五个错误时无济于事。 不确定这种情况在野外有多常见（在我的大多数项目中都很常见），但我担心try()可能会鼓励人们对每个函数使用通用包装器，即使包装不同的错误是有意义的不同。

只是一个带有小样本集数据支持的快速评论：

我们提出了一个名为 try 的新内置函数，专门设计用于消除 Go 中通常与错误处理相关的样板 if 语句

如果这是该提案要解决的核心问题，我发现这个“样板”仅占我在数十个公开可用的开源项目中代码的 1.4%，总计约 60k SLOC。

好奇是否有其他人有类似的统计数据？

在像 Go 本身这样一个更大的代码库上，总共约 160 万条 SLOC，这相当于代码库的约 0.5% 具有像if err != nil这样的行。

这真的是用 Go 2 解决的最有影响力的问题吗？

非常感谢@griesemer花时间了解每个人的想法并明确提供想法。 我认为这确实有助于人们在此过程中听到社区的声音。

1. @pierrec建议 gofmt 可以适当地格式化 try 表达式以使它们更加可见。
   或者，可以通过允许 gofmt 格式化 if 语句在一行上检查错误（@zeebo）来使现有代码更紧凑。

1. 使用gofmt来格式化try表达式，使其更加可见当然是一种选择。 但是当在表达式中使用时，它会失去try的一些好处。

这些是关于要求gofmt格式化try的有价值的想法，但我很感兴趣是否有任何特别的想法在gofmt允许if语句检查错误是一行。 该提案与try的格式混为一谈，但我认为这是一个完全正交的事情。 谢谢。

@griesemer感谢您完成所有评论并回答大部分（如果不是全部）反馈的令人难以置信的工作🎉

您的反馈中没有解决的一件事是使用 Go 语言的工具/审查部分来改善错误处理体验的想法，而不是更新 Go 语法。

例如，随着新 LSP ( gopls ) 的登陆，它似乎是分析函数签名并为开发人员处理错误处理样板的完美场所，同时也进行了适当的包装和审查。

@griesemer我确信这没有经过深思熟虑，但我试图将您的建议修改为更接近我在这里会感到舒服的东西： https ://www.reddit.com/r/golang/comments/bwvyhe

@zeebo在一行上制作gofmt格式if err != nil { return ...., err }很容易。 大概它只适用于这种特定类型的if模式，而不是所有“短” if语句？

同样，有人担心try是不可见的，因为它与业务逻辑在同一条线上。 我们有所有这些选择：

当前风格：

a, b, c, ... err := BusinessLogic(...)
if err != nil {
   return ..., err
}

一行if ：

a, b, c, ... err := BusinessLogic(...)
if err != nil { return ..., err }

try在单独的行 (!)：

a, b, c, ... err := BusinessLogic(...)
try(err)

try建议：

a, b, c := try(BusinessLogic(...))

第一行和最后一行似乎是最清楚的（对我来说），尤其是当有人习惯于识别try时。 在最后一行中，明确检查了一个错误，但由于它（通常）不是主要操作，所以它在后台更多一些。

@marwan-at-work 我不确定您建议这些工具为您做什么。 您是否建议他们以某种方式隐藏错误处理？

@dpinela

@guybrand这似乎是一个完全不同的提议； 我认为您应该将其作为自己的问题提交，以便该问题可以专注于讨论@griesemer的提案。

IMO 我的建议仅在语法上有所不同，意思是：

• 目标在内容和优先级上是相似的。
• 在自己的行中捕获每个错误并相应地（如果不是 nil）在通过处理程序函数时退出函数的想法是相似的（伪 asm - 它是“jnz”和“调用”）。
• 这甚至意味着函数体中的行数（没有延迟）和流看起来完全一样（因此 AST 可能也会变得相同）

所以主要的区别是我们是否使用 try(func()) 包装原始函数调用，它总是会分析最后一个 var 以 jnz 调用或使用实际返回值来做到这一点。

我知道它看起来不同，但实际上在概念上非常相似。
另一方面 - 如果你采取通常的尝试....catch 很多类似 c 的语言 - 那将是一个非常不同的实现，不同的可读性等。

然而，我确实认真考虑写一个提案，谢谢你的想法。

@griesemer

我不确定您建议这些工具为您做什么。 您是否建议他们以某种方式隐藏错误处理？

恰恰相反：我建议gopls可以选择为您编写错误处理样板。

正如您在上一条评论中提到的：

这个提议的原因是 Go 社区提到错误处理（特别是相关的样板代码）是 Go 中的一个重要问题（在缺乏泛型旁边）

所以问题的核心是程序员最终编写了很多样板代码。 所以问题是关于写作，而不是阅读。 因此，我的建议是：让计算机（工具/gopls）通过分析函数签名并放置适当的错误处理子句来为程序员编写代码。

例如：

// user begins to write this function: 
func openFile(path string) ([]byte, error) {
  file, err := os.Open(path)
  defer file.Close()
  bts, err := ioutil.ReadAll(file)
  return bts, nil
}

然后用户触发该工具，可能只需保存文件（类似于 gofmt/goimports 通常的工作方式）， gopls将查看此函数，分析其返回签名并将代码扩充为：

// user has triggered the tool (by saving the file, or code action)
func openFile(path string) ([]byte, error) {
  file, err := os.Open(path)
  if err != nil {
    return nil, fmt.Errorf("openFile: %w", err)
  }
  defer file.Close()
  bts, err := ioutil.ReadAll(file)
  if err != nil {
    return nil, fmt.Errorf("openFile: %w", err)
  }
  return bts, nil
}

这样，我们得到了两全其美：我们获得了当前错误处理系统的可读性/明确性，并且程序员没有编写任何错误处理样板。 更好的是，用户可以在以后继续修改错误处理块以执行不同的行为： gopls可以理解该块存在，并且不会修改它。

该工具如何知道我打算稍后在函数中处理err而不是提前返回？ 尽管很少见，但我仍然编写了代码。

如果以前有人提出过这个问题，我深表歉意，但我找不到任何提及。

try(DoSomething())对我来说很好读，而且很有意义：代码正在尝试做某事。 try(err) ，OTOH，从语义上讲，感觉有点不对劲：如何尝试错误？ 在我看来，可以_test_ 或_check_ 一个错误，但_trying_ 似乎不对。

我确实意识到允许try(err)出于一致性的原因很重要：我想如果try(DoSomething())有效，但err := DoSomething(); try(err)没有，那会很奇怪。 不过，感觉try(err)在页面上看起来有点尴尬。 我想不出任何其他内置函数可以如此容易地看起来如此奇怪。

我对此事没有任何具体的建议，但我仍然想发表这一看法。

@griesemer谢谢。 实际上，该提案仅适用于return ，但我怀疑允许任何单个语句成为单行会很好。 例如，在测试中，无需更改测试库，就可以拥有

if err != nil { t.Fatal(err) }

第一行和最后一行似乎是最清楚的（对我来说），尤其是当有人习惯于识别 try 是什么时。 在最后一行中，明确检查了一个错误，但由于它（通常）不是主要操作，所以它在后台更多一些。

最后一行隐藏了一些成本。 如果您想注释错误，我相信社区已经口头表示这是理想的最佳实践并且应该受到鼓励，您将不得不更改函数签名以命名参数并希望单个defer应用于函数体中的每一个出口，否则try没有价值； 由于它的易用性，甚至可能是负面的。

我没有更多要补充的，我相信还没有说过。

我没有看到如何从设计文档中回答这个问题。 这段代码有什么作用：

func foo() (err error) {
    src := try(getReader())
    if src != nil {
        n, err := src.Read(nil)
        if err == io.EOF {
            return nil
        }
        try(err)
        println(n)
    }
    return nil
}

我的理解是它会脱糖成

func foo() (err error) {
    tsrc, te := getReader()
    if err != nil {
        err = te
        return
    }
    src := tsrc

    if src != nil {
        n, err := src.Read(nil)
        if err == io.EOF {
            return nil
        }

        terr := err
        if terr != nil {
            err = terr
            return
        }

        println(n)
    }
    return nil
}

编译失败，因为err在裸返回期间被遮蔽。 这不会编译吗？ 如果是这样，那是一个非常微妙的失败，而且似乎不太可能发生。 如果没有，那么除了一些糖之外，还有更多的事情发生。

@marwan-at-work

正如您在上一条评论中提到的：

这个提议的原因是 Go 社区提到错误处理（特别是相关的样板代码）是 Go 中的一个重要问题（在缺乏泛型旁边）

所以问题的核心是程序员最终编写了很多样板代码。 所以问题是关于写作，而不是阅读。

我认为实际上是相反的——对我来说，当前错误处理样板的最大烦恼不是必须输入它，而是它如何将函数的快乐路径垂直分散在屏幕上，使其更难理解一眼。 这种效果在 I/O 繁重的代码中尤其明显，其中通常每两个操作之间都有一个样板块。 即使CopyFile的简化版本也需要大约 20 行代码，尽管它实际上只执行五个步骤：开源、延迟关闭源、打开目标、复制源 -> 目标、关闭目标。

当前语法的另一个问题是，正如我之前提到的，如果您有一个操作链，每个操作都可能返回错误，那么当前语法会强制您为所有中间结果命名，即使您更愿意留下一些匿名的。 当这种情况发生时，它也会损害可读性，因为您必须花费大脑周期来解析这些名称，即使它们不是很有信息量。

我喜欢try在单独的行上。
我希望它可以独立指定handler func。

func try(error, optional func(error)error)

func (p *pgStore) DoWork() error {
    tx, err := p.handle.Begin()
    try(err)

    handle := func(err error) error {
        tx.Rollback()
        return err
    }

    var res int64
    _, err = tx.QueryRow(`INSERT INTO table (...) RETURNING c1`, ...).Scan(&res)
    try(err, handle)

    _, err = tx.Exec(`INSERT INTO table2 (...) VALUES ($1)`, res)
    try(err, handle)

    return tx.Commit()
}

@zeebo ：我给出的例子是 1:1 翻译。 第一个（传统的if ）没有处理错误，其他的也没有。 如果第一个处理了错误，并且如果这是在函数中检查错误的唯一位置，那么第一个示例（使用if ）可能是编写代码的合适选择。 如果有多个错误检查，所有这些都使用相同的错误处理（包装），比如说因为它们都添加了有关当前函数的信息，那么可以使用defer语句在一个地方处理所有错误。 或者，可以将if重写为try （或不理会它们）。 如果要检查多个错误，并且它们都以不同的方式处理错误（这可能表明该函数的关注范围太广并且可能需要拆分），则使用if是要走的路。 是的，有不止一种方法可以做同样的事情，正确的选择取决于代码以及个人品味。 虽然我们在 Go 中确实为“做一件事的一种方式”而努力，但这当然已经不是这种情况了，尤其是对于常见的构造。 例如，当if - else - if序列变得太长时，有时switch可能更合适。 有时，变量声明var x int比x := 0更能表达意图，依此类推（尽管不是每个人都对此感到高兴）。

关于您关于“重写”的问题：不，不会出现编译错误。 请注意，重写发生在内部（并且可能比代码模式建议的更有效），编译器无需抱怨隐藏返回。 在您的示例中，您在嵌套范围内声明了一个本地err变量。 当然， try仍然可以直接访问结果err变量。 重写可能看起来更像这样。

[编辑] PS：更好的答案是： try不是赤裸裸的回报（即使重写看起来像它）。 毕竟，明确地给try一个参数，该参数包含（或是）如果不是nil则返回的错误。 裸返回的影子错误是源错误（不是源的底层翻译。编译器不需要该错误。

如果总体函数的最终返回类型不是错误类型，我们会恐慌吗？

它将使内置功能更加通用（例如满足我在 #32219 中的关注）

@pjebs这已被考虑并决定反对。 请阅读详细的设计文档（明确提及您在此主题上的问题）。

我还想指出 try() 被视为表达式，即使它用作 return 语句。 是的，我知道 try 是内置宏，但我猜大多数用户会像函数式编程一样使用它。

func doSomething() (error, error, error, error, error) {
   ...
}

try(try(try(try(try(doSomething)))))

该设计表明您使用panic进行了探索，而不是返回错误。

我强调一个细微的区别：

完全按照您当前的提案所述执行，除了删除总体函数必须具有error类型的最终返回类型的限制。

如果它没有error的最终返回类型 => 恐慌
如果使用 try 进行包级变量声明 => 恐慌（消除对MustXXX( )约定的需要）

对于单元测试，适度的语言变化。

@mattn ，我非常怀疑有多少人会编写这样的代码。

@pjebs ，这种语义——如果当前函数中没有错误导致恐慌——正是设计文档在https://github.com/golang/proposal/blob/master/design/32437-try-builtin 中讨论的内容。 md#讨论。

此外，为了使 try 不仅仅在有错误结果的函数内部有用，try 的语义取决于上下文：如果在包级别使用 try，或者如果在没有错误结果的函数内部调用它， try 在遇到错误时会恐慌。 （顺便说一句，由于该属性，在该提案中，内置函数被称为 must 而不是 try。） try（或 must）以这种上下文敏感的方式运行似乎很自然，也非常有用：它允许消除当前在包级变量初始化表达式中使用的许多用户定义的必须辅助函数。 它还将打开通过测试包在单元测试中使用 try 的可能性。

然而，try 的上下文敏感性被认为是令人担忧的：例如，如果从签名中添加或删除错误结果，则包含 try 调用的函数的行为可能会静默变化（从可能恐慌到不恐慌，反之亦然）。 这似乎太危险的财产。 显而易见的解决方案是将 try 的功能拆分为两个单独的函数，must 和 try（非常类似于 issue #31442 的建议）。 但这需要两个新的内置函数，只有 try 直接连接到对更好的错误处理支持的迫切需要。

@pjebs这正是我们在先前提案中考虑的内容（参见详细文档，设计迭代部分，第 4 段）：

此外，为了使 try 不仅仅在有错误结果的函数内部有用，try 的语义取决于上下文：如果在包级别使用 try，或者如果在没有错误结果的函数内部调用它， try 在遇到错误时会恐慌。 （顺便说一句，由于该属性，内置函数被称为 must 而不是在该提案中尝试。）

（Go 团队内部）的共识是，如果try依赖于上下文并采取如此不同的行为方式，将会令人困惑。 例如，将错误结果添加到函数（或删除它）可以默默地将函数的行为从恐慌更改为不恐慌（反之亦然）。

@griesemer感谢您对重写的澄清。 我很高兴它会编译。

我知道这些示例是没有注释错误的翻译。 我试图争辩说try使得在常见情况下对错误进行良好的注释变得更加困难，并且错误注释对社区非常重要。 到目前为止，大部分评论都在探索为try添加更好的注释支持的方法。

关于必须以不同的方式处理错误，我不同意这表明该功能的关注范围太广。 我一直在翻译评论中声称的真实代码的一些示例，并将它们放在我原始评论底部的下拉列表中，以及https://github.com/golang/go/issues/32437#issuecomment中的示例 - 499007288 我认为很好地展示了一个常见的案例：

func (c *Config) Build() error {
    pkgPath, err := c.load()
    if err != nil { return nil, errors.WithMessage(err, "load config dir") }

    b := bytes.NewBuffer(nil)
    err = templates.ExecuteTemplate(b, "main", c)
    if err != nil { return nil, errors.WithMessage(err, "execute main template") }

    buf, err := format.Source(b.Bytes())
    if err != nil { return nil, errors.WithMessage(err, "format main template") }

    target := fmt.Sprintf("%s.go", filename(pkgPath))
    err = ioutil.WriteFile(target, buf, 0644)
    if err != nil { return nil, errors.WithMessagef(err, "write file %s", target) }
    // ...
}

该函数的目的是将某些数据的模板执行到文件中。 我不认为它需要被拆分，如果所有这些错误都刚刚获得了它们从延迟中创建的界限，那将是不幸的。 这对开发人员来说可能没问题，但对用户来说用处要小得多。

我认为这也是一个信号，即defer wrap(&err, "message: %v", err)错误是多么微妙，即使是经验丰富的 Go 程序员，它们也是如何绊倒的。

总结一下我的论点：我认为错误注释比基于表达式的错误检查更重要，我们可以通过允许基于语句的错误检查为一行而不是三行来减少噪音。 谢谢。

@griesemer抱歉，我阅读了另一个讨论恐慌的部分，但没有看到对危险的讨论。

@zeebo感谢这个例子。 在这种情况下，使用if语句似乎是正确的选择。 但是要指出的是，将 if 格式化为单行可能会简化这一点。

我想再次提出处理程序作为try的第二个参数的想法，但另外处理程序参数是_required_，但可以为零。 这使得处理错误成为默认值，而不是异常。 如果您确实希望将错误原封不动地向上传递，只需向处理程序提供一个 nil 值， try的行为将与原始提案中一样，但 nil 参数将充当视觉提示，即错误没有被处理。 在代码审查期间会更容易捕获。

file := try(os.Open("my_file.txt"), nil)

如果提供了处理程序但为 nil 会发生什么？ 应该尝试恐慌还是将其视为缺失的错误处理程序？

如上所述， try将按照最初的提议行事。 不会有诸如缺少错误处理程序之类的东西，只有一个 nil 。

如果调用处理程序时出现非 nil 错误，然后返回 nil 结果怎么办？ 这是否意味着错误已“取消”？ 或者封闭函数是否应该返回一个 nil 错误？

我相信封闭函数会返回 nil 错误。 如果try有时即使在收到非 nil 错误值后仍能继续执行，这可能会非常令人困惑。 这将允许处理程序在某些情况下“处理”错误。 例如，此行为在“获取或创建”样式函数中可能很有用。

func getOrCreateObject(obj *object) error {
    defaultObjectHandler := func(err error) error {
        if err == ObjectDoesNotExistErr {
            *obj = object{}
            return nil
        }
        return fmt.Errorf("getting or creating object: %v", err)
    }

    *obj = try(db.getObject(), defaultObjectHandler)
}

也不清楚允许可选的错误处理程序是否会导致程序员完全忽略正确的错误处理。 在任何地方进行适当的错误处理也很容易，但会错过一次尝试。 等等。

我相信通过使处理程序成为必需的、可为零的论点，可以缓解这两个问题。 它要求程序员做出一个有意识的、明确的决定，即他们不会处理他们的错误。

作为奖励，我认为需要错误处理程序也会阻止深度嵌套的try s，因为它们不那么简短。 有些人可能认为这是一个缺点，但我认为这是一个好处。

@velovix我喜欢这个想法，但为什么必须需要错误处理程序？ 不能默认是nil吗？ 为什么我们需要“视觉线索”？

@griesemer如果采用了@velovix想法，但builtin包含一个将 err 转换为 panic 的预定义函数，并且我们删除了过度架构函数具有错误返回值的要求怎么办？

这个想法是，如果总体函数不返回错误，则使用没有错误处理程序的try是编译时错误。

错误处理程序还可用于在错误位置使用各种库等包装即将返回的错误，而不是顶部的defer修改命名的返回错误。

@pjebs

为什么必须需要错误处理程序？ 不能默认为 nil 吗？ 为什么我们需要“视觉线索”？

这是为了解决人们的担忧

1. 现在的try提案可能会阻止人们为他们的错误提供上下文，因为这样做并不是那么简单。

首先有一个处理程序可以更容易地提供上下文，并且将处理程序作为一个必需的参数会发送一条消息：常见的推荐情况是以某种方式处理或上下文化错误，而不是简单地将其传递到堆栈上。 这符合 Go 社区的一般建议。

1. 原始提案文件中的一个问题。 我在第一条评论中引用了它：

也不清楚允许可选的错误处理程序是否会导致程序员完全忽略正确的错误处理。 在任何地方进行适当的错误处理也很容易，但会错过一次尝试。 等等。

必须传递明确的nil使得忘记正确处理错误变得更加困难。 您必须明确决定不处理错误，而不是通过省略参数来隐式处理。

进一步考虑在https://github.com/golang/go/issues/32437#issuecomment -498947603 中简要提到的条件返回。
它似乎
return if f, err := os.Open("/my/file/path"); err != nil
会更符合 Go 现有的if的外观。

如果我们为return if语句添加一条规则，
当最后一个条件表达式（如err != nil ）不存在时，return if语句中声明的最后一个变量是error类型，那么最后一个变量的值将自动与nil作为隐式条件进行比较。

那么return if语句可以简写为：
return if f, err := os.Open("my/file/path")

这非常接近try提供的信噪比。
如果我们将return if更改为try ，它将变为
try f, err := os.Open("my/file/path")
它再次变得类似于此线程中try的其他提议变体，至少在语法上如此。
就个人而言，在这种情况下，我仍然更喜欢return if而不是try ，因为它使函数的退出点非常明确。 例如，在调试时，我经常在编辑器中突出显示关键字return以识别大型函数的所有退出点。

不幸的是，对于插入调试日志的不便，它似乎也没有足够的帮助。
除非我们还允许body块用于return if ，例如
原版的：

        return if f, err := os.Open("my/path") 

调试时：

-       return if f, err := os.Open("my/path") 
+       return if f, err := os.Open("my/path") {
+               fmt.Printf("DEBUG: os.Open: %s\n", err)
+       }

我假设return if的主体块的含义是显而易见的。 它将在defer之前执行并返回。

也就是说，我对 Go 中现有的错误处理方法没有任何抱怨。
我更担心添加新的错误处理将如何影响 Go 目前的优点。

@velovix我们非常喜欢带有显式处理函数作为第二个参数的try的想法。 但正如设计文档所述，有太多问题没有明显的答案。 您以您认为合理的方式回答了其中一些问题。 很有可能（这是我们在 Go 团队中的经验），其他人认为正确的答案是完全不同的。 例如，您说应该始终提供 handler 参数，但它可以是nil ，为了明确表示我们不关心处理错误。 现在，如果提供一个函数值（不是nil文字），而该函数值（存储在变量中）恰好为 nil，会发生什么？ 通过与显式nil值类比，不需要处理。 但其他人可能会争辩说这是代码中的错误。 或者，另一种可能是允许零值处理程序参数，但是在某些情况下，一个函数可能会不一致地处理错误，而在其他情况下则不是，而且从代码中不一定很明显，因为它看起来好像总是存在处理程序. 另一个论点是最好有一个错误处理程序的顶级声明，因为这很清楚该函数确实处理错误。 因此defer 。 可能还有更多。

了解更多有关此问题的信息会很好。 当前使用 if 语句来测试错误的编码风格是尽可能明确的。 逐个（针对每个 if）向错误添加附加信息非常容易。 通常，以统一的方式处理函数中检测到的所有错误是有意义的，这可以通过 defer 来完成——这现在已经成为可能。 事实上，我们已经拥有了语言中用于良好错误处理的所有工具，以及处理程序构造与 defer 不正交的问题，这导致我们放弃了一种仅用于增加错误的新机制。

@griesemer -IIUC，您是说对于与调用站点相关的错误上下文，当前的 if 语句很好。 然而，这个新的try函数对于在一个地方处理多个错误很有用的情况很有用。

我相信担心的是，虽然在某些情况下简单地执行if err != nil { return err}可能没问题，但通常建议在返回之前修饰错误。 而这个提议似乎解决了前者，对后者没有多大作用。 这实质上意味着人们将被鼓励使用easy-return模式。

@agnivade你是对的，这个建议对错误装饰没有任何帮助（但建议使用defer ）。 一个原因是为此的语言机制已经存在。 一旦需要错误修饰，尤其是在单个错误的基础上，修饰代码的额外源文本量使得if相比之下不那么繁琐。 在不需要装饰的情况下，或者装饰总是相同的情况下，样板变成了可见的麻烦，然后减损了重要的代码。

人们已经被鼓励使用易于返回的模式， try或不使用try ，只是写得更少了。 想一想，_鼓励错误修饰的唯一方法是强制执行_，因为无论有什么语言支持，修饰错误都需要更多的工作。

使交易更甜蜜的一种方法是只允许像try （或任何类似的快捷符号） _if_ 在某处提供显式（可能为空）处理程序（请注意，原始设计草案没有这样的要求，要么）。

我不确定我们想走这么远。 让我重申一下，很多完美的代码，比如库的内部，不需要到处修饰错误。 例如，在它们离开 API 入口点之前向上传播并修饰它们是很好的。 （事实上​​，到处装饰它们只会导致过度装饰的错误，在隐藏真正的罪魁祸首的情况下，更难找到重要的错误；就像过于冗长的日志记录会让人很难看到真正发生的事情）。

我认为我们还可以添加一个catch函数，这将是一个不错的组合，所以：

func a() int {
  x := randInt()
  // let's assume that this is what recruiters should "fix" for us
  // or this happens in 3rd-party package.
  if x % 1337 != 0 {
    panic("not l33t enough")
  }
  return x
}

func b() error {
  // if a() panics, then x = 0, err = error{"not l33t enough"}
  x, err := catch(a())
  if err != nil {
    return err
  }
  sendSomewhereElse(x)
  return nil
}

// which could be simplified even further

func c() error {
  x := try(catch(a()))
  sendSomewhereElse(x)
  return nil
}

在此示例中， catch()将recover()恐慌和return ..., panicValue 。
当然，我们有一个明显的极端情况，其中我们有一个函数，它也返回一个错误。 在这种情况下，我认为只传递错误值会很方便。

所以，基本上，你可以使用 catch() 来实际恢复（）恐慌并将它们变成错误。
这对我来说看起来很有趣，因为 Go 实际上没有异常，但在这种情况下，我们有非常简洁的 try()-catch() 模式，它也不应该用 Java ( catch(Throwable)在 Main + throws LiterallyAnything ）。 您可以轻松处理某人的恐慌，就像那些通常的错误一样。 在我当前的项目中，我目前在 Go 中有大约 600 万+ LoC，我认为这至少对我来说会简化事情。

@griesemer感谢您对讨论的回顾。

我注意到其中遗漏了一点：有些人认为我们应该等待这个特性，直到我们有了泛型，这有望让我们以更优雅的方式解决这个问题。

此外，我也喜欢@velovix的建议，虽然我很欣赏这引发了规范中描述的一些问题，但我认为这些可以很容易地以合理的方式得到回答，就像@velovix已经做过的那样。

例如：

• 如果提供一个函数值（不是 nil 文字），而该函数值（存储在变量中）恰好为 nil，会发生什么？ => 不要处理错误，句号。 这在错误处理取决于上下文并且根据是否需要错误处理来设置处理程序变量的情况下很有用。 这不是一个错误，而是一个功能。 :)

• 另一个论点是最好有一个错误处理程序的顶级声明，因为这很清楚该函数确实处理错误。 => 所以将函数顶部的错误处理程序定义为命名的闭包函数并使用它，所以也很清楚应该处理错误。 这不是一个严重的问题，更多的是风格要求。

还有哪些其他担忧？ 我很确定他们都可以以合理的方式得到类似的回答。

最后，正如您所说，“如果某处提供了明确的（可能为空的）处理程序，则一种使交易更甜蜜的方法是只允许尝试（或任何类似的快捷方式符号）之类的东西”。 我认为如果我们要继续这个提议，我们实际上应该“走这么远”，以鼓励正确的、“显式优于隐式”的错误处理。

@griesemer

现在，如果提供一个函数值（不是 nil 文字），而该函数值（存储在变量中）恰好为 nil，会发生什么？ 通过与显式 nil 值类比，不需要处理。 但其他人可能会争辩说这是代码中的错误。

从理论上讲，这似乎确实是一个潜在的陷阱，尽管我很难概念化一个合理的情况，即处理程序最终会意外地为零。 我想处理程序最常见的要么来自其他地方定义的实用函数，要么来自函数本身中定义的闭包。 这些都不可能意外地变为 nil。 从理论上讲，您可能会遇到处理函数作为参数传递给其他函数的场景，但在我看来，这似乎有些牵强。 也许有一种我不知道的模式。

另一个论点是最好有一个错误处理程序的顶级声明，因为这很清楚该函数确实处理错误。 因此defer 。

正如@beoran 所提到的，将处理程序定义为函数顶部附近的闭包在风格上看起来非常相似，这就是我个人期望人们最常使用处理程序的方式。 虽然我很欣赏所有处理错误的函数都将使用defer这一事实所带来的清晰性，但当一个函数需要在函数中途调整其错误处理策略时，它可能变得不太清楚。 然后，将有两个defer可供查看，读者将不得不推理它们将如何相互交互。 在这种情况下，我相信处理程序的论点会更加清晰和符合人体工程学，而且我确实认为这将是一个_相对_常见的场景。

是否可以在没有括号的情况下使其工作？

即类似的东西：
a := try func(some)

@Cyber​​ax - 如上所述，在发布之前仔细阅读设计文档非常重要。 由于这是一个高流量的问题，有很多人订阅。

该文档详细讨论了运算符与函数。

我喜欢这个比我喜欢八月的版本要多得多。

我认为大部分负面反馈，并不完全反对没有return关键字的退货，可以总结为两点：

1. 人们不喜欢命名结果参数，这在大多数情况下都是必需的
2. 它不鼓励为错误添加详细的上下文

参见例如：

• https://github.com/golang/go/issues/32437#issuecomment -498937169
• https://github.com/golang/go/issues/32437#issuecomment -498967099
• https://github.com/golang/go/issues/32437#issuecomment -499194787
• https://github.com/golang/go/issues/32437#issuecomment -499309304

对这两个反对意见的反驳分别是：

1. “我们认为 [命名结果参数] 没问题”
2. “没有人会让你使用try ”/它不适用于 100% 的情况

关于 1，我真的没有什么要说的（我对此感觉不强烈）。 但是关于2，我注意到八月的提案没有这个问题，大多数反提案也没有这个问题。

特别是tryf反提案（在此线程中独立发布了两次）和try(X, handlefn)反提案（这是设计迭代的一部分）都没有这个问题。

我认为很难说try会促使人们远离使用相关上下文装饰错误，而转向单个通用的每个函数错误装饰。

由于这些原因，我认为值得尝试解决这个问题，并且我想提出一个可能的解决方案：

1. 目前defer的参数只能是函数或方法调用。 允许defer也有函数名或函数字面量，即

defer func(...) {...}
defer packageName.functionName

1. 当 panic 或 deferreturn 遇到这种类型的 defer 时，它们会调用函数，为它们的所有参数传递零值

2. 允许try有多个参数

3. 当try遇到新类型的 defer 时，它会调用函数，将指向错误值的指针作为第一个参数传递，然后是try自己的所有参数，除了第一个参数。

例如，给定：

func errorfn() error {
    return errors.New("an error")
}


func f(fail bool) {
    defer func(err *error, a, b, c int) {
        fmt.Printf("a=%d b=%d c=%d\n", a, b, c)
    }
    if fail {
        try(errorfn, 1, 2, 3)
    }
}

将发生以下情况：

f(false)        // prints "a=0 b=0 c=0"
f(true)         // prints "a=1 b=2 c=3"

@zeebo 在https://github.com/golang/go/issues/32437#issuecomment -499309304中的代码可以重写为：

func (c *Config) Build() error {
    defer func(err *error, msg string, args ...interface{}) {
        if *err == nil || msg == "" {
            return
        }
        *err = errors.WithMessagef(err, msg, args...)
    }
    pkgPath := try(c.load(), "load config dir")

    b := bytes.NewBuffer(nil)
    try(templates.ExecuteTemplate(b, "main", c), "execute main template")

    buf := try(format.Source(b.Bytes()), "format main template")

    target := fmt.Sprintf("%s.go", filename(pkgPath))
    try(ioutil.WriteFile(target, buf, 0644), "write file %s", target)
    // ...
}

并将 ErrorHandlef 定义为：

func HandleErrorf(err *error, format string, args ...interface{}) {
        if *err != nil && format != "" {
                *err = fmt.Errorf(format + ": %v", append(args, *err)...)
        }
}

将免费为每个人提供备受追捧的tryf ，而无需将fmt样式的格式字符串拉入核心语言。

此功能向后兼容，因为defer不允许函数表达式作为其参数。 它不会引入新的关键字。
除了https://github.com/golang/proposal/blob/master/design/32437-try-builtin.md中概述的更改之外，实现它需要进行的更改是：

1. 教解析器关于新的延迟
2. 更改类型检查器以检查函数内部所有具有函数作为参数（而不是调用）的延迟也具有相同的签名
3. 更改类型检查器以检查传递给try的参数是否与传递给defer的函数的签名匹配
4. 更改后端 (?) 以生成适当的 deferproc 调用
5. 更改try的实现以在遇到由新类型的 defer 延迟的调用时将其参数复制到延迟调用的参数中。

在check/handle草案设计的复杂性之后，我很惊喜地看到这个更简单实用的提案落地，尽管我对它遭到如此多的反对感到失望。

诚然，很多回击来自那些对目前的冗长（一个完全合理的立场）非常满意并且可能不会真正欢迎任何减轻它的建议的人。 对于我们其他人来说，我认为这个建议达到了简单和类似 Go 的最佳点，不要尝试做太多事情，并且与现有的错误处理技术相吻合，如果try并没有完全按照您的意愿行事。

关于一些具体点：

1. 我唯一不喜欢该提案的是在使用defer时需要有一个命名的错误返回参数，但是，话虽如此，我想不出任何其他不会与之冲突的解决方案其他语言的工作方式。 所以我认为，如果提案获得通过，我们将不得不接受这一点。

2. 遗憾的是try不能很好地与不返回错误值的函数的测试包配合使用。 我自己的首选解决方案是拥有第二个内置函数（可能是ptry或must ），它总是在遇到非零错误时恐慌而不是返回，因此可能是与上述功能一起使用（包括main ）。 虽然这个想法在当前的提案迭代中被拒绝了，但我给人的印象是它是一个“近距离电话”，因此它可能有资格重新考虑。

3. 我认为人们很难理解go try(f)或defer try(f)正在做什么，因此最好完全禁止它们。

4. 我同意那些认为如果go fmt不重写单行if语句，现有的错误处理技术看起来不那么冗长的观点。 就个人而言，我更喜欢一个简单的规则，无论是否涉及错误处理，这都将被允许用于 _any_ 单个语句if 。 事实上，我一直无法理解为什么在编写单行函数时当前不允许这样做，其中主体放置在与允许声明相同的行上。

在装饰错误的情况下

func myfunc()( err error){
try(thing())
defer func(){
err = errors.Wrap(err,"more context")
}()
}

这感觉比现有的范式更加冗长和痛苦，并且不像检查/处理那样简洁。 非包装的 try() 变体更简洁，但感觉就像人们最终会混合使用 try，并返回简单的错误。 我不确定我是否喜欢混合尝试和简单错误返回的想法，但我完全被装饰错误所吸引（并期待 Is/As）。 让我觉得虽然这在语法上很简洁，但我不确定我是否想要实际使用它。 检查/处理感觉我会更彻底地接受。

我真的很喜欢这种简单性和“做好一件事”的方法。 在我的GoAWK解释器中，这将非常有帮助——我有大约 100 个if err != nil { return nil }结构，它可以简化和整理，而且这是在一个相当小的代码库中。

我已经阅读了将其设为内置而不是关键字的提案的理由，归结为不必调整解析器。 但这对于编译器和工具编写者来说不是一个相对较小的痛苦吗，而拥有额外的括号和 this-looks-like-a-function-but-isn't 的可读性问题将是所有 Go 编码器和代码的问题-读者不得不忍受。 在我看来，“但是panic()确实控制流”的论点（借口？:-）并没有削减它，因为恐慌和恢复本质上是例外的，而try()会是正常的错误处理和控制流。

即使按原样进行，我也会非常感激，但我强烈希望正常控制流清晰，即通过关键字完成。

我赞成这个提议。 它避免了我对先前提案的最大保留： handle相对于defer的非正交性。

我想提两个我认为上面没有强调的方面。

首先，虽然这个提议并不容易将特定于上下文的错误文本添加到错误中，但它_确实_使得向错误添加堆栈帧错误跟踪信息变得容易：https: //play.golang.org/p /YL1MoqR08E6

其次， try可以说是解决https://github.com/golang/go/issues/19642 中大多数问题的公平解决方案。 以该问题为例，您可以使用try来避免每次都写出所有返回值。 当返回具有长名称的按值结构类型时，这也可能很有用。

func (f *Font) viewGlyphData(b *Buffer, x GlyphIndex) (buf []byte, offset, length uint32, err error) {
    xx := int(x)
    if f.NumGlyphs() <= xx {
        try(ErrNotFound)
    }
    i := f.cached.locations[xx+0]
    j := f.cached.locations[xx+1]
    if j < i {
        try(errInvalidGlyphDataLength)
    }
    if j-i > maxGlyphDataLength {
        try(errUnsupportedGlyphDataLength)
    }
    buf, err = b.view(&f.src, int(i), int(j-i))
    return buf, i, j - i, err
}

我也喜欢这个提议。

我有一个要求。

像make一样，我们可以允许try接受可变数量的参数吗

• 尝试（f）：
  如上。
  返回错误值是强制性的（作为最后一个返回参数）。
  最常用的模型
• 尝试（f，doPanic bool）：
  如上，但如果 doPanic，则 panic(err) 而不是返回。
  在这种模式下，不需要返回错误值。
• 尝试（f，fn）：
  如上所述，但在返回之前调用 fn(err)。
  在这种模式下，不需要返回错误值。

这样，它是一个可以处理所有用例的内置程序，同时仍然是明确的。 它的优点：

• 总是显式的——不需要推断是恐慌还是设置错误并返回
• 支持特定于上下文的处理程序（但没有处理程序链）
• 支持没有错误返回变量的用例
• 支持 must(...) 语义

虽然重复的if err !=nil { return ... err }肯定是一个丑陋的口吃，但我同意那些
谁认为 try() 提案的可读性非常低并且有些含糊。
命名返回的使用也是有问题的。

如果需要这种整理，为什么不将try(err)作为语法糖
if err !=nil { return err } ：

file, err := os.Open("file.go")
try(err)

为了

file, err := os.Open("file.go")
if err != nil {
   return err
}

如果有多个返回值， try(err)可能是return t1, ... tn, err
其中 t1, ... tn 是其他返回值的零值。

这个建议可以避免命名返回值的需要，并且，
在我看来，更容易理解和更具可读性。

更好的是，我认为应该是：

file, try(err) := os.Open("file.go")

甚至

file, err? := os.Open("file.go")

最后一个是向后兼容的（标识符中目前不允许使用？）。

（此建议与 https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback#recurring-themes 相关。但重复出现的主题示例似乎有所不同，因为那是在仍在讨论显式句柄而不是离开的阶段推迟。）

感谢 go 团队提出的这个细心、有趣的提议。

@rogpeppe评论如果try自动添加堆栈框架，而不是我，我可以不鼓励添加上下文。

@aarzilli - 所以根据你的建议，每次我们向tryf提供额外参数时，都必须使用 defer 子句吗？

如果我这样做会发生什么

try(ioutil.WriteFile(target, buf, 0644), "write file %s", target)

并且不编写延迟函数？

@agnivade

如果我这样做 (...) 并且不编写延迟函数会发生什么？

类型检查错误。

在我看来，使用try来避免写出所有返回值实际上只是对它的又一次打击。

func (f *Font) viewGlyphData(b *Buffer, x GlyphIndex) (buf []byte, offset, length uint32, err error) {
    xx := int(x)
    if f.NumGlyphs() <= xx {
        try(ErrNotFound)
    }
    //...

我完全理解避免写出return nil, 0, 0, ErrNotFound的愿望，但我更愿意以其他方式解决这个问题。

try这个词并不意味着“返回”。 这就是它在这里的使用方式。 我实际上更希望提案更改，以便try不能直接获取error值，因为我不希望任何人编写这样的代码 ^^ 。 它读错了。 如果您向新手展示该代码，他们将不知道该尝试在做什么。

如果我们想要一种方法来轻松地返回默认值和错误值，让我们单独解决。 也许另一个内置的

return default(ErrNotFound)

至少这符合某种逻辑。

但是，我们不要滥用try来解决其他问题。

@natefinch如果try内置函数在原始提案中被命名为check ，那么它将是check(err) ，它读起来要好得多，imo。

撇开这一点不谈，我不知道写try(err)是否真的是一种滥用。 它完全超出了定义。 但是，另一方面，这也意味着这是合法的：

a, b := try(1, f(), err)

我想我对try的主要问题是它实际上只是一个panic只上升一个级别......除了不像恐慌，它是一个表达式，而不是一个语句，所以你可以隐藏它在某处的语句中间。 这几乎比恐慌更糟糕。

@natefinch如果您将其概念化为一种恐慌，它会上升一个级别然后做其他事情，这似乎很混乱。 但是，我对它的概念不同。 Go 中返回错误的函数实际上是返回一个 Result, 粗略地借用 Rust 的术语。 try是一个实用程序，它解包结果，如果 error != nil 则返回“错误结果”，如果error != nil error == nil解包结果的 T 部分。

当然，在 Go 中我们实际上没有结果对象，但它实际上是相同的模式， try似乎是该模式的自然编码。 我相信这个问题的任何解决方案都必须对错误处理的某些方面进行编码，并且try对我来说似乎是合理的。 我和其他人建议稍微扩展try的功能以更好地适应现有的 Go 错误处理模式，但基本概念保持不变。

@ugorji您提出的try(f, bool)变体听起来像 #32219 中的must 。

@ugorji您提出的try(f, bool)变体听起来像 #32219 中的must 。

是的。 我只是觉得这三个案例都可以用一个单一的内置函数来处理，并优雅地满足所有用例。

由于try()已经很神奇，并且知道错误返回值，是否可以扩展它以在以空值（零参数）形式调用时也返回指向该值的指针？ 这将消除命名返回的需要，而且我相信，这有助于在视觉上关联延迟语句中预期错误的来源。 例如：

func foo() error {
  defer fmt.HandleErrorf(try(), "important foo context info")
  try(bar())
  try(baz())
  try(etc())
}

@ugorji
我认为try(f, bool)上的布尔值会使其难以阅读且容易错过。 我喜欢你的提议，但对于恐慌的情况，我认为用户可以在第三个子弹的处理程序中编写它，例如try(f(), func(err error) { panic('at the disco'); }) ，这对于用户来说比隐藏的try(f(), true)更明确

@ugorji
我认为try(f, bool)上的布尔值会使其难以阅读且容易错过。 我喜欢你的提议，但对于恐慌的情况，我认为用户可以在第三个子弹的处理程序中编写它，例如try(f(), func(err error) { panic('at the disco'); }) ，这对于用户来说比隐藏的try(f(), true)更明确

进一步思考，我倾向于同意你的立场和推理，它仍然看起来像单线一样优雅。

@patrick-nyt 仍然是 _assignment syntax_ 触发 nil 测试的另一个支持者，在https://github.com/golang/go/issues/32437#issuecomment -499533464

这个概念出现在对检查/处理提案的 13 个单独的响应中
https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback#recurring -themes

f, ?return := os.Open(...)
f, ?panic  := os.Open(...)

为什么？ 因为它读起来像 Go 1，而try()和check不是。

https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling-overview.md#draft -design

对try的一个反对意见似乎是它是一个表达式。 假设有一个一元后缀语句?表示如果不是 nil 则返回。 这是标准代码示例（假设添加了我建议的延迟包）：

func CopyFile(src, dst string) error {
    var err error // Don't need a named return because err is explicitly named
    defer deferred.Annotate(&err, "copy %s %s", src, dst)

    r, err := os.Open(src)
    err?
    defer deferred.AnnotatedExec(&err, r.Close)

    w, err := os.Create(dst)
    err?
    defer deferred.AnnotatedExec(&err, r.Close)

    defer deferred.Cond(&err, func(){ os.Remove(dst) })
    _, err = io.Copy(w, r)

    return err
}

pgStore 示例：

func (p *pgStore) DoWork() error {
    tx, err := p.handle.Begin()
    err?

    defer deferred.Cond(&err, func(){ tx.Rollback() })

    var res int64 
    err = tx.QueryRow(`INSERT INTO table (...) RETURNING c1`, ...).Scan(&res)
    // tricky bit: this would not change the value of err 
    // but the deferred.Cond would still be triggered by err being set before
    deferred.Format(err, "insert table")?

    _, err = tx.Exec(`INSERT INTO table2 (...) VALUES ($1)`, res)
    deferred.Format(err, "insert table2")?

    return tx.Commit()
}

我喜欢@jargv 的这个：

由于 try() 已经很神奇，并且知道错误返回值，是否可以扩展它以在以空值（零参数）形式调用时也返回指向该值的指针？ 这将消除命名回报的需要

但不是根据参数的数量重载名称try ，我认为可能有另一个内置的魔法，比如reterr或其他东西。

我已经简要介绍了一些经常使用的包，寻找“遭受”错误处理但在编写之前必须经过深思熟虑的 go 代码，试图弄清楚提议的 try() 会做什么“魔法”。
目前，除非我误解了该提议，否则其中许多（例如，不是超级基本错误处理）不会获得太多收益，或者必须保持“旧”错误处理风格。
来自 net/http/request.go 的示例：

func (r *Request) write(w io.Writer, usingProxy bool, extraHeaders Header, waitForContinue func() bool) (err error) {
`

trace := httptrace.ContextClientTrace(r.Context())
if trace != nil && trace.WroteRequest != nil {
    defer func() {
        trace.WroteRequest(httptrace.WroteRequestInfo{
            Err: err,
        })
    }()
}

// Find the target host. Prefer the Host: header, but if that
// is not given, use the host from the request URL.
//
// Clean the host, in case it arrives with unexpected stuff in it.
host := cleanHost(r.Host)
if host == "" {
    if r.URL == nil {
        return errMissingHost
    }
    host = cleanHost(r.URL.Host)
}

// According to RFC 6874, an HTTP client, proxy, or other
// intermediary must remove any IPv6 zone identifier attached
// to an outgoing URI.
host = removeZone(host)

ruri := r.URL.RequestURI()
if usingProxy && r.URL.Scheme != "" && r.URL.Opaque == "" {
    ruri = r.URL.Scheme + "://" + host + ruri
} else if r.Method == "CONNECT" && r.URL.Path == "" {
    // CONNECT requests normally give just the host and port, not a full URL.
    ruri = host
    if r.URL.Opaque != "" {
        ruri = r.URL.Opaque
    }
}
if stringContainsCTLByte(ruri) {
    return errors.New("net/http: can't write control character in Request.URL")
}
// TODO: validate r.Method too? At least it's less likely to
// come from an attacker (more likely to be a constant in
// code).

// Wrap the writer in a bufio Writer if it's not already buffered.
// Don't always call NewWriter, as that forces a bytes.Buffer
// and other small bufio Writers to have a minimum 4k buffer
// size.
var bw *bufio.Writer
if _, ok := w.(io.ByteWriter); !ok {
    bw = bufio.NewWriter(w)
    w = bw
}

_, err = fmt.Fprintf(w, "%s %s HTTP/1.1\r\n", valueOrDefault(r.Method, "GET"), ruri)
if err != nil {
    return err
}

// Header lines
_, err = fmt.Fprintf(w, "Host: %s\r\n", host)
if err != nil {
    return err
}
if trace != nil && trace.WroteHeaderField != nil {
    trace.WroteHeaderField("Host", []string{host})
}

// Use the defaultUserAgent unless the Header contains one, which
// may be blank to not send the header.
userAgent := defaultUserAgent
if r.Header.has("User-Agent") {
    userAgent = r.Header.Get("User-Agent")
}
if userAgent != "" {
    _, err = fmt.Fprintf(w, "User-Agent: %s\r\n", userAgent)
    if err != nil {
        return err
    }
    if trace != nil && trace.WroteHeaderField != nil {
        trace.WroteHeaderField("User-Agent", []string{userAgent})
    }
}

// Process Body,ContentLength,Close,Trailer
tw, err := newTransferWriter(r)
if err != nil {
    return err
}
err = tw.writeHeader(w, trace)
if err != nil {
    return err
}

err = r.Header.writeSubset(w, reqWriteExcludeHeader, trace)
if err != nil {
    return err
}

if extraHeaders != nil {
    err = extraHeaders.write(w, trace)
    if err != nil {
        return err
    }
}

_, err = io.WriteString(w, "\r\n")
if err != nil {
    return err
}

if trace != nil && trace.WroteHeaders != nil {
    trace.WroteHeaders()
}

// Flush and wait for 100-continue if expected.
if waitForContinue != nil {
    if bw, ok := w.(*bufio.Writer); ok {
        err = bw.Flush()
        if err != nil {
            return err
        }
    }
    if trace != nil && trace.Wait100Continue != nil {
        trace.Wait100Continue()
    }
    if !waitForContinue() {
        r.closeBody()
        return nil
    }
}

if bw, ok := w.(*bufio.Writer); ok && tw.FlushHeaders {
    if err := bw.Flush(); err != nil {
        return err
    }
}

// Write body and trailer
err = tw.writeBody(w)
if err != nil {
    if tw.bodyReadError == err {
        err = requestBodyReadError{err}
    }
    return err
}

if bw != nil {
    return bw.Flush()
}
return nil

}
`

或用于彻底的测试，例如 pprof/profile/profile_test.go：
`
func checkAggregation(prof *Profile, a *aggTest) 错误 {
// 检查是否保留了行的样本总数。
总计 := int64(0)

samples := make(map[string]bool)
for _, sample := range prof.Sample {
    tb := locationHash(sample)
    samples[tb] = true
    total += sample.Value[0]
}

if total != totalSamples {
    return fmt.Errorf("sample total %d, want %d", total, totalSamples)
}

// Check the number of unique sample locations
if a.rows != len(samples) {
    return fmt.Errorf("number of samples %d, want %d", len(samples), a.rows)
}

// Check that all mappings have the right detail flags.
for _, m := range prof.Mapping {
    if m.HasFunctions != a.function {
        return fmt.Errorf("unexpected mapping.HasFunctions %v, want %v", m.HasFunctions, a.function)
    }
    if m.HasFilenames != a.fileline {
        return fmt.Errorf("unexpected mapping.HasFilenames %v, want %v", m.HasFilenames, a.fileline)
    }
    if m.HasLineNumbers != a.fileline {
        return fmt.Errorf("unexpected mapping.HasLineNumbers %v, want %v", m.HasLineNumbers, a.fileline)
    }
    if m.HasInlineFrames != a.inlineFrame {
        return fmt.Errorf("unexpected mapping.HasInlineFrames %v, want %v", m.HasInlineFrames, a.inlineFrame)
    }
}

// Check that aggregation has removed finer resolution data.
for _, l := range prof.Location {
    if !a.inlineFrame && len(l.Line) > 1 {
        return fmt.Errorf("found %d lines on location %d, want 1", len(l.Line), l.ID)
    }

    for _, ln := range l.Line {
        if !a.fileline && (ln.Function.Filename != "" || ln.Line != 0) {
            return fmt.Errorf("found line %s:%d on location %d, want :0",
                ln.Function.Filename, ln.Line, l.ID)
        }
        if !a.function && (ln.Function.Name != "") {
            return fmt.Errorf(`found file %s location %d, want ""`,
                ln.Function.Name, l.ID)
        }
    }
}

return nil

}
`
这是我能想到的两个例子，其中一个会说：“我想要一个更好的错误处理选项”

有人可以演示如何使用 try() 改进这些吗？

我主要赞成这个提议。

我与许多评论者分享的主要关注点是命名结果参数。 当前的提案当然鼓励更多地使用命名结果参数，我认为这是一个错误。 我不认为这只是提案所述的风格问题：命名结果是该语言的一个微妙特征，在许多情况下，它会使代码更容易出错或不太清晰。 在阅读和编写 Go 代码约 8 年之后，我真的只将命名结果参数用于两个目的：

• 结果参数的文档
• 在 defer 中操作结果值（通常是error ）

为了从一个新的方向来解决这个问题，我认为这个想法与设计文档或这个问题评论线程中讨论的任何内容都不太一致。 让我们称之为“错误延迟”：

允许使用 defer 调用带有隐式错误参数的函数。

所以如果你有一个功能

func f(err error, t1 T1, t2 T2, ..., tn Tn) error

然后，在最后一个结果参数类型error的函数g中（即，我使用try的任何函数），调用f可以延期如下：

func g() (R0, R0, ..., error) {
    defer f(t0, t1, ..., tn) // err is implicit
}

error-defer 的语义是：

1. 对f的最后一个结果参数作为g f第一个输入参数来调用
2. f仅在错误不为零时调用
3. f的结果赋值给g的最后一个结果参数

因此，要使用旧错误处理设计文档中的示例，使用错误延迟和尝试，我们可以这样做

func printSum(a, b string) error {
    defer func(err error) error {
        return fmt.Errorf("printSum(%q + %q): %v", a, b, err)
    }()
    x := try(strconv.Atoi(a))
    y := try(strconv.Atoi(b))
    fmt.Println("result:", x+y)
    return nil
}

HandleErrorf 的工作原理如下：

func printSum(a, b string) error {
    defer handleErrorf("printSum(%q + %q)", a, b)
    x := try(strconv.Atoi(a))
    y := try(strconv.Atoi(b))
    fmt.Println("result:", x+y)
    return nil
}

func handleErrorf(err error, format string, args ...interface{}) error {
    return fmt.Errorf(format+": %v", append(args, err)...)
}

需要解决的一个极端情况是如何处理我们使用哪种形式的延迟不明确的情况。 我认为这只发生在（非常不寻常的）具有这样签名的函数中：

func(error, ...error) error

可以合理地说这种情况是以非错误延迟方式处理的（并且这保持了向后兼容性）。

最近几天想了想这个想法，有点神奇，但是避免命名结果参数是对其有利的一大优势。 由于try鼓励更多地使用defer进行错误操作，因此可以扩展defer以更好地适应该目的是有道理的。 此外， try和 error-defer 之间存在一定的对称性。

最后，即使没有尝试，error-defers 在今天也很有用，因为它们取代了使用命名结果参数来处理错误返回。 例如，这里是一些真实代码的编辑版本：

// GetMulti retrieves multiple files through the cache at once and returns its
// results as a slice parallel to the input.
func (c *FileCache) GetMulti(keys []string) (_ []*File, err error) {
    files := make([]*file, len(keys))

    defer func() {
        if err != nil {
            // Return any successfully retrieved files.
            for _, f := range files {
                if f != nil {
                    c.put(f)
                }
            }
        }
    }()

    // ...
}

使用错误延迟，这变成：

// GetMulti retrieves multiple files through the cache at once and returns its
// results as a slice parallel to the input.
func (c *FileCache) GetMulti(keys []string) ([]*File, error) {
    files := make([]*file, len(keys))

    defer func(err error) error {
        // Return any successfully retrieved files.
        for _, f := range files {
            if f != nil {
                c.put(f)
            }
        }
        return err
    }()

    // ...
}

@beoran关于您的评论，我们应该等待泛型。 泛型在这里无济于事 - 请阅读常见问题解答。

关于您对@velovix的 2 参数try的默认行为的建议：正如我之前所说，您对什么是明显合理的选择的想法是别人的噩梦。

我是否可以建议，一旦广泛的共识演变成带有显式错误处理程序的try比当前最小的try更好的主意，我们是否可以继续讨论。 在这一点上，讨论这种设计的细节是有意义的。

（就此而言，我确实喜欢有一个处理程序。这是我们早期的提议之一。如果我们按原样采用try ，我们仍然可以在前锋中使用一个处理程序的try - 兼容的方式 - 至少如果处理程序是可选的。但让我们一次迈出一步。）

@aarzilli感谢您的建议。

只要装饰错误是可选的，人们就会倾向于不这样做（毕竟这是额外的工作）。 另请参阅我的评论。

所以，我不认为建议的try _discourages_ 人从装饰错误（由于上述原因，即使使用if ，他们也已经气馁了）； 是try没有_鼓励_它。

（鼓励它的一种方法是将其绑定到try ：如果一个人也修饰错误，或者明确选择退出，则只能使用try 。）

但回到你的建议：我认为你在这里引入了更多的机器。 改变defer的语义只是为了让它更好地为try工作不是我们想要考虑的事情，除非这些defer更改以更一般的方式有益。 此外，您的建议将defer与try $ 联系在一起，从而使这两种机制不那么正交； 我们想要避免的事情。

但更重要的是，我怀疑你会想强迫每个人都写一个defer以便他们可以使用try 。 但如果不这样做，我们又回到了第一个问题：人们会倾向于不修饰错误。

（就此而言，我确实喜欢有一个处理程序。这是我们早期的提议之一。如果我们按原样采用 try ，我们仍然可以以向前兼容的方式使用处理程序进行尝试 - 至少如果处理程序是可选的。但让我们一步一步来。）

当然，也许多步骤的方法是要走的路。 如果我们将来添加一个可选的处理程序参数，则可以创建工具来警告编写者未处理的try ，其精神与errcheck工具相同。 无论如何，我感谢您的反馈！

@alanfo感谢您的积极反馈。

关于你提出的观点：

1）如果try的唯一问题是必须命名错误返回，以便我们可以通过defer修饰错误，我认为我们很好。 如果命名结果是一个真正的问题，我们可以解决它。 我能想到的一个简单机制是预先声明的变量，它是错误结果的别名（将其视为包含触发最近try的错误）。 可能会有更好的想法。 我们没有提出这个，因为语言中已经有一种机制，就是给结果命名。
2) try和测试：可以解决这个问题并使其发挥作用。 请参阅详细文档。
3）这在详细文档中明确解决。
4) 承认。

@benhoyt感谢您的积极反馈。

如果反对这个提议的主要论点是try是内置的，那么我们就处于一个很好的位置。 使用内置只是向后兼容问题的实用解决方案（它恰好不会导致解析器和工具等的额外工作 - 但这只是一个很好的附带好处，而不是主要原因）。 必须写括号也有一些好处，这在设计文档中详细讨论（关于提议设计的属性部分）。

综上所述，如果使用内置插件，我们应该考虑try关键字。 它不会与现有代码向后兼容，因为关键字可能与现有标识符冲突。

（为了完整起见，还可以选择诸如?之类的运算符，这将是向后兼容的。不过，我认为它并不是 Go 等语言的最佳选择。但同样，如果这就是使try可口所需的全部，我们也许应该考虑一下。）

@ugorji感谢您的积极反馈。

try可以扩展为采用额外的参数。 我们的偏好是只采用带有签名func (error) error的函数。 如果你想恐慌，很容易提供一个辅助函数：

func doPanic(err error) error { panic(err) }

最好保持try的设计简单。

@patrick-nyt 你的建议是什么：

file, err := os.Open("file.go")
try(err)

目前的提案将是可能的。

@dpinela ， @ugorji 另请阅读有关must与try主题的设计文档。 最好让try尽可能简单。 must是初始化表达式中的常见“模式”，但没有迫切需要“修复”它。

@jargv感谢您的建议。 这是一个有趣的想法（另请参阅我在此主题上的评论）。 总结一下：

• try(x)按建议运行
• try()返回指向错误结果的*error

这确实是另一种无需命名即可获得结果的方法。

@cespare @jargv的建议对我来说看起来比你提出的要简单得多。 它解决了访问结果错误的相同问题。 你怎么看？

根据https://github.com/golang/go/issues/32437#issuecomment -499320588：

func doPanic（错误错误）错误{恐慌（错误）}

我预计这个功能会很常见。 这可以在“内置”（或标准包中的其他地方，例如errors ）中预定义吗？

太糟糕了，你没有预料到泛型足够强大来实现
试试看，我实际上希望有可能这样做。

是的，这个提议可能是第一步，虽然我看不出有多大用处
它自己现在的样子。

诚然，这个问题可能过于关注详细的替代方案，
但这表明许多参与者并不完全满意
它。 似乎缺乏的是对该提案的广泛共识......

操作 vr 6 月 7 日。 2019 01:04 schreef pj [email protected] ：

Asper #32437（评论）
https://github.com/golang/go/issues/32437#issuecomment-499320588 ：

func doPanic（错误错误）错误{恐慌（错误）}

我预计这个功能会很常见。 这可以预定义吗
在“内置”中？

—
你收到这个是因为你被提到了。
直接回复此邮件，在 GitHub 上查看
https://github.com/golang/go/issues/32437?email_source=notifications&email_token=AAARM6OOOLLYO5ZCE6VVL2TPZGJWRA5CNFSM4HTGCZ72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXEMYZY#issuecomment-499698791
或使线程静音
https://github.com/notifications/unsubscribe-auth/AAARM6K5AOR2DES4QDTNLSTPZGJWRANCNFSM4HTGCZ7Q
.

@pjebs ，我已经写了几十次等效函数。 我通常称之为“orDie”或“check”。 它是如此简单，没有真正需要将其作为标准库的一部分。 另外，不同的人可能想要在终止之前进行日志记录或其他任何事情。

@beoran也许您可以扩展泛型和错误处理之间的联系。 当我想到它们时，它们似乎是两种不同的东西。 泛型并不是一个可以解决语言所有问题的包罗万象的方法。 它是编写可以对多种类型进行操作的单个函数的能力。

这个特定的错误处理提议试图通过引入一个预先声明的函数try来减少样板文件，该函数在某些情况下会更改流控制。 泛型永远不会改变控制流。 所以我真的看不出这种关系。

我对此的最初反应是👎，因为我想象在一个函数中处理几个容易出错的调用会使defer错误处理令人困惑。 在阅读了整个提案之后，我将我的反应转变为 ❤️ 和 👍，因为我了解到这仍然可以以相对较低的复杂性来实现。

@carlmjohnson是的，这很简单，但是...

我已经写了几十次等效的函数。

预声明函数的优点是：

1. 我们可以单行
2. 我们不需要在我们使用的每个包中重新声明 err => panic 函数，或者为它维护一个公共位置。 由于可能对 Go 社区中的每个人都很常见，因此“标准包”是它的_ _ 通用位置。

@griesemer使用原始 try 提议的错误处理程序变体，现在不再需要返回错误的总体功能要求。

当我第一次询问 err => panic 时，有人指出该提案考虑了它，但认为它太危险了（有充分的理由）。 但是，如果我们在总体函数不返回错误的情况下使用try()而没有错误处理程序，则将其变为编译时错误可以缓解提案中讨论的问题

@pjebs原始设计中不需要返回错误的总体功能要求_if_ 提供了错误处理程序。 但这只是try的另一个并发症。 _much_ 最好保持简单。 相反，有一个单独的must函数会更清楚，它总是在出错时恐慌（但其他方面就像try ）。 然后很明显代码中发生了什么，并且不必查看上下文。

拥有这样一个must的主要吸引力在于它可以与单元测试一起使用； 特别是如果testing包被适当地调整以从must引起的恐慌中恢复并以一种很好的方式将它们报告为测试失败。 但是，当我们可以调整测试包以接受TestXxx(t *testing.T) error形式的测试功能时，为什么还要添加另一种新的语言机制呢？ 如果他们返回一个错误，这似乎很自然（也许我们应该从一开始就这样做），那么try就可以正常工作。 本地测试需要更多的工作，但它可能是可行的。

must的另一个相对常见的用途是全局初始化表达式（ must(regexp.Compile...等）。 如果将是“很高兴拥有”，但这并不一定会将其提高到新语言功能所需的水平。

@griesemer鉴于must与try模糊相关，并且考虑到try得到实施的势头，您认为考虑must不是很好吗

很有可能，如果在这一轮中没有讨论它，它就不会得到实施/认真考虑，至少在 3 年以上（或者可能永远）。 讨论中的重叠也将是好的，而不是从头开始和循环讨论。

许多人说must try 。

@pjebs现在似乎没有任何“实现try的势头”...... - 而且我们也只是在两天前发布了这个。 也没有任何决定。 让我们给这个时间。

我们并没有忘记must与try很好地吻合，但这与使其成为语言的一部分不同。 我们只是开始与更广泛的人群一起探索这个空间。 我们真的不知道会出现什么支持或反对它。 谢谢。

在花了几个小时阅读了所有的评论和详细的设计文档之后，我想在这个提案中添加我的观点。

我将尽我所能尊重@ianlancetaylor的要求，不仅要重申以前的观点，还要在讨论中添加新的评论。 但是，我认为如果不参考先前的评论，我就无法发表新的评论。

关注点

不幸的延迟重载

将defer的明显而直接的性质重载的偏好令人震惊。 如果我写的defer closeFile(f)对我来说是直截了当的，发生了什么以及为什么； 在将被调用的函数的末尾。 虽然将defer用于panic()和recover()不太明显，但我很少使用它，并且在阅读其他人的代码时几乎从未见过它。

欺骗以重载defer以处理错误并不明显且令人困惑。 为什么是关键字defer ？ defer不是表示_“以后做”_而不是_“也许以后做？”_

Go 团队还提到了对defer性能的担忧。 鉴于此， defer被考虑用于_“热路径”_ 代码流似乎是双重不幸的。

没有验证重要用例的统计数据

正如@prologic 所提到的，这个try()提案是基于将使用此用例的大部分代码，还是基于试图安抚那些抱怨 Go 错误处理的人？

我希望我知道如何从我的代码库中为您提供统计信息，而无需详尽地查看每个文件并做笔记； 我不知道@prologic是如何做到的，尽管他很高兴。

但有趣的是，如果try()解决了我 5% 的用例，我会感到惊讶，并且怀疑它会解决不到 1% 的用例。 您确定其他人的结果大不相同吗？ 您是否采用了标准库的一个子集并尝试了解如何应用它？

因为没有已知的统计数据表明这适用于大量的代码，所以我不得不问，这种新的复杂的语言变化是否需要每个人都学习新概念，真的解决了许多令人信服的用例？

使开发人员更容易忽略错误

这是对其他人的评论的完全重复，但基本上提供try()在许多方面类似于简单地将以下内容作为惯用代码，这是永远不会进入任何代码的代码- 尊重开发者船只：

f, _ := os.Open(filename)

我知道我可以在自己的代码中做得更好，但我也知道我们中的许多人依赖于发布一些非常有用的包的其他 Go 开发人员的慷慨，但是从我在_“其他人的代码（tm）”中看到的内容来看_错误处理的最佳实践经常被忽略。

说真的，我们真的想让开发人员更容易忽略错误并允许他们用非健壮的包污染 GitHub 吗？

可以（大部分）已经在用户空间中实现try()

除非我误解了这个提议——我可能会这样做——这里是在 userland 中实现的 Go Playground 中的try() ，尽管只有一 (1) 个返回值并返回一个接口而不是预期的类型：

package main

import (
    "errors"
    "fmt"
    "strings"
)
func main() {
    defer func() {
        r := recover()
        if r != nil && strings.HasPrefix(r.(string),"TRY:") {
            fmt.Printf("Ouch! %s",strings.TrimPrefix(r.(string),"TRY: "))
        }
    }()
    n := try(badjuju()).(int)
    fmt.Printf("Just chillin %dx!",n)   
}
func badjuju() (int,error) {
    return 10, errors.New("this is a really bad error")
}
func try(args ...interface{}) interface{} {
    err,ok := args[1].(error)
    if ok && err != nil {
        panic(fmt.Sprintf("TRY: %s",err.Error()))
    }
    return args[0]
}

因此，用户可以添加try2() 、 try3()等等，具体取决于他们需要返回多少返回值。

但是 Go 只需要一 (1) 个简单但通用的语言功能，以允许想要try()的用户推出自己的支持，尽管仍然需要显式类型断言。 为 Go func添加 _(完全向后兼容)_ 功能以返回可变数量的返回值，例如：

func try(args ...interface{}) ...interface{} {
    err,ok := args[1].(error)
    if ok && err != nil {
        panic(fmt.Sprintf("TRY: %s",err.Error()))
    }
    return args[0:len(args)-2]
}

如果你首先解决泛型，那么类型断言甚至都不需要_（尽管我认为应该通过添加内置函数来解决泛型的用例而不是添加泛型的混淆语义和语法沙拉来减少泛型的用例来自 Java 等）_

缺乏明显性

在研究提案的代码时，我发现这种行为并不明显，而且有点难以推理。

当我看到try()包装了一个表达式时，如果返回错误会发生什么？

错误会被忽略吗？ 或者它会跳转到第一个或最近的defer ，如果是这样，它会自动在闭包内设置一个名为err的变量，还是将它作为参数传递_(I没有看到参数？）_。 如果不是自动错误名称，我该如何命名？ 这是否意味着我不能在我的函数中声明自己的err变量以避免冲突？

它会调用所有defer吗？ 逆序还是正序？

或者它会从闭包和返回错误的func中返回吗？ _（如果我没有在这里读到暗示这一点的话，我永远不会考虑的事情。）_

在阅读了提案和迄今为止的所有评论之后，老实说，我仍然不知道上述问题的答案。 这是我们想要添加到倡导者拥护_“Captain Obvious”的语言的那种功能吗？

缺乏控制

使用defer ，似乎开发人员唯一能获得的控制权就是分支到 _(最新的？)_ defer 。 但根据我对任何方法的经验，除了琐碎的func之外，它通常比这更复杂。

我经常发现在func内共享错误处理方面很有帮助——甚至在package内共享——但也可以在一个或多个其他包之间共享更具体的处理。

例如，我可以调用五 (5) func调用，它们从另一个func中返回一个error() #$ ； 让我们将它们标记为A() 、 B() 、 C() 、 D()和E() 。 我可能需要C()有自己的错误处理， A() 、 B() 、 D()和E()来共享一些错误处理，和B()和E()进行特定处理。

但我不相信通过这个提议可以做到这一点。 至少不容易。

然而具有讽刺意味的是，Go 已经具有允许高度灵活性的语言特性，而不必局限于一小部分用例。 func和闭包。 所以我的反问是：

_ “为什么我们不能对现有语言进行轻微的改进来解决这些用例，而不需要添加新的内置函数或接受令人困惑的语义？” _

这是一个反问，因为我计划提交一个提案作为替代方案，这是我在研究该提案并考虑其所有缺点时构想的。

但我离题了，这将在稍后进行，此评论是关于为什么需要重新考虑当前提案。

缺乏对break的明确支持

这可能感觉它来自左侧字段，因为大多数人使用早期返回来进行错误处理，但我发现最好使用break进行错误处理，在return之前包装大部分或全部 func

我已经使用这种方法一段时间了，它在简化重构方面的好处使得它比早期return更可取，但它还有其他几个好处，包括单个退出点和能够提前终止一段 func 但仍然可以能够运行清理_（这可能是我很少使用defer的原因，我发现在程序流程方面更难推理。）_

要使用break而不是提前返回，请使用for range "1" {...}循环创建一个块，以便从 _ 退出中断（我实际上创建了一个名为only的包，它只包含一个常量名为Once ，值为"1" ):_

func (me *Config) WriteFile() (err error) {
    for range only.Once {
        var j []byte
        j, err = json.MarshalIndent(me, "", "    ")
        if err != nil {
            err = fmt.Errorf("unable to marshal config; %s", 
                err.Error(),
            )
            break
        }
        err = me.MaybeMakeDir(me.GetDir(), os.ModePerm)
        if err != nil {
            err = fmt.Errorf("unable to make directory'%s'; %s", 
                me.GetDir(), 
                err.Error(),
            )
            break
        }
        err = ioutil.WriteFile(string(me.GetFilepath()), j, os.ModePerm)
        if err != nil {
            err = fmt.Errorf("unable to write to config file '%s'; %s", 
                me.GetFilepath(), 
                err.Error(),
            )
            break
        }
    }
    return err
}

我计划在不久的将来详细介绍这种模式，并讨论为什么我发现它比早期回报更有效的几个原因。

但我离题了。 我在这里提出它的原因是我必须让 Go 实现错误处理，假设早期return s 并忽略使用break进行错误处理

我的意见err == nil是有问题的

作为进一步的题外话，我想提出我对 Go 中惯用错误处理的担忧。 虽然我非常相信 Go 的哲学，即在错误发生时处理错误与使用异常处理，但我觉得使用nil表示没有错误是有问题的，因为我经常发现我想从一个例程——用于 API 响应——不仅在出现错误时返回非零值。

所以对于 Go 2，我真的很想看到 Go 考虑添加一个新的内置类型status和三个内置函数iserror() 、 iswarning() 、 issuccess() 。 status可以实现error — 允许向后兼容，并且传递给issuccess()的nil值将返回true — 但status将有一个额外的错误级别内部状态，因此错误级别的测试将始终使用内置函数之一完成，理想情况下永远不要使用nil检查。 这将允许采用以下方法：

func (me *Config) WriteFile() (sts status) {
    for range only.Once {
        var j []byte
        j, sts = json.MarshalIndent(me, "", "    ")
        if iserror(sts) {
            sts.AddMessage("unable to marshal config")
            break
        }
        sts = me.MaybeMakeDir(me.GetDir(), os.ModePerm)
        if iserror(sts) {
            sts.AddMessage("unable to make directory'%s'", me.GetDir())
            break
        }
        sts = ioutil.WriteFile(string(me.GetFilepath()), j, os.ModePerm)
        if iserror(sts) {
            sts.AddMessage("unable to write to config file '%s'", 
                me.GetFilepath(), 
            )
            break
        }
        sts = fmt.Status("config file written")
    }
    return sts
}

我已经在测试前级别的当前内部使用包中使用了用户态方法，该包类似于上面的错误处理。 坦率地说，与我尝试遵循惯用的 Go 错误处理时相比，在使用这种方法时考虑如何构建代码的时间要少得多。

如果您认为有任何机会将惯用的 Go 代码演变为这种方法，请在实施错误处理时将其考虑在内，包括在考虑此try()提案时。

_“不适合所有人”_理由

Go 团队的主要回应之一是 _“同样，该提案并未尝试解决所有错误处理情况。”_
从治理的角度来看，这可能是最令人担忧的问题。

这种需要每个人都学习新概念的语言的新复杂变化真的解决了大量令人信服的用例吗？

这难道不是核心团队成员拒绝社区众多功能请求的同一理由吗？ 以下是 Go 团队成员在对大约 2 年前提交的功能请求的原型回复中发表的评论的直接引用 _（我没有命名此人或特定功能请求，因为此讨论不应该能够人，而不是语言）：_

_“一种新的语言特性需要引人注目的用例。所有语言特性都是有用的，否则没有人会提出它们；问题是：它们是否有用到足以证明使语言复杂化并要求每个人都学习新概念是合理的？有什么引人注目的用途这里的案例？人们将如何使用这些？例如，人们是否希望能够......如果是这样，他们将如何做到这一点？这个提议是否不仅仅让你......？
— Go 团队的核心成员

坦率地说，当我看到这些回复时，我有两种感觉之一：

1. 如果这是我同意的功能，则表示愤慨，或者
2. 如果这是我不同意的功能，我会很高兴。

但在任何一种情况下，我的感受都是/无关紧要的； 我理解并同意 Go 是我们许多人选择开发的语言的部分原因是出于对语言纯度的嫉妒保护。

这就是为什么这个提议让我如此困扰的原因，因为 Go 核心团队似乎正在深入研究这个提议，就像一个教条式地想要一个 Go 社区绝对不会容忍的深奥功能的人一样。

_（我真的希望团队不会向信使开枪，并将其视为来自希望看到 Go 继续成为我们所有人最好的人的建设性批评，因为我将不得不被视为“不受欢迎的人”核心团队。）_

如果需要一组令人信服的真实世界用例是所有社区生成的功能提案的标准，那么它不应该也是_所有_ 功能提案的标准吗？

try() 的嵌套

这也被一些人所覆盖，但我想在try()和对三元运算符的持续请求之间进行比较。 引用大约 18 个月前另一位 Go 团队成员的评论：

_“当“大型编程”（大型团队长时间使用大型代码库）时，代码的读取频率比编写代码的频率高，因此我们优化可读性，而不是可写性。”_

不添加三元运算符的主要原因之一是嵌套时它们难以阅读和/或容易误读。 然而，像try(try(try(to()).parse().this)).easily())这样的嵌套try()语句也是如此。

反对三元运算符的其他原因是它们是_“表达式”_，其中嵌套表达式会增加复杂性。 但是try()不也创建一个可嵌套的表达式吗？

现在这里有人说 _“我认为像 [nested try() s] 这样的例子是不切实际的”_ 并且该声明没有受到挑战。

但是，如果人们接受开发人员不会嵌套try()的假设，那么当人们说_“我认为深度嵌套的三元运算符不现实？”时，为什么不尊重三元运算符？

对于这一点，我认为如果反对三元运算符的论点真的有效，那么它们也应该被视为反对这个try()提案的有效论点。

总之

在撰写本文时， 58%反对票对42%赞成票。 我认为仅此一项就足以表明，这是一个足以引起分歧的提案，是时候在这个问题上重新制定计划了。

关注

PS 说得更诙谐，我认为我们应该遵循尤达的意译智慧：

_"没有try() 。只有do() 。"_

@ianlancetaylor

@beoran也许您可以扩展泛型和错误处理之间的联系。

不代表@beoran ，但在我几分钟前的评论中，您会看到如果我们有泛型_（加上可变参数返回参数）_，那么我们可以构建自己的try() 。

然而——我将在这里重复我上面所说的关于泛型的内容，这样更容易看到：

_" 我认为应该通过添加内置函数来解决泛型的用例来减少泛型的用例，而不是添加来自 Java 等的泛型的令人困惑的语义和语法沙拉)"_

@ianlancetaylor

在尝试为您的问题制定答案时，我尝试按原样在 Go 中实现try函数，令我高兴的是，实际上已经可以模拟非常相似的东西：

func try(v interface{}, err error) interface{} {
   if err != nil { 
     panic(err)
   }
   return v
}

在这里查看如何使用它：https: //play.golang.org/p/Kq9Q0hZHlXL

这种方法的缺点是：

1. 需要延迟救援，但在此提案中使用try ，如果我们想要进行适当的错误处理，还需要延迟处理程序。 所以我觉得这不是一个严重的缺点。 如果 Go 有某种super(arg1, ..., argn)内置函数会更好如果你愿意的话。
2. 我实现的这个try只能与返回单个结果和错误的函数一起使用。
3. 您必须键入 assert 返回的 emtpy 接口结果。

足够强大的泛型可以解决问题 2 和 3，只剩下 1，这可以通过添加super()来解决。 有了这两个功能，我们可以得到类似的东西：

func (T ... interface{})try(T, err error) super {
   if err != nil { 
      super(err)
   }
  super(T...)
}

这样就不再需要延迟的救援了。 即使没有向 Go 添加泛型，这种好处也将可用。

实际上，这个 super() 内置函数的想法是如此强大和有趣，我可能会单独发布一个提案。

@beoran很高兴看到我们在用户空间中独立实现try()时遇到了完全相同的限制，除了我没有包括的超级部分，因为我想在替代提案中讨论类似的东西。 :-)

我喜欢这个提议，但事实上你必须明确指定defer try(...)和go try(...)是不允许的，这让我觉得有些事情不太正确......正交性是一个很好的设计指南。 关于进一步阅读和看到类似的东西
x = try(foo(...)) y = try(bar(...))
我想知道是否可能是try需要是一个上下文！ 考虑：
try ( x = foo(...) y = bar(...) )
这里foo()和bar()返回两个值，第二个是error 。 尝试语义只对try块内的调用很重要，其中返回的错误值被省略（没有接收者）而不是被忽略（接收者是_ ）。 您甚至可以处理foo和bar调用之间的一些错误。

概括：
a) 由于语法原因， go和defer的不允许try的问题消失了。
b) 可以排除多个功能的错误处理。
c) 它的神奇本质用特殊语法比用函数调用更好地表达。

如果 try 是一个上下文，那么我们刚刚制作了我们特别试图避免的 try/catch 块（并且有充分的理由）

没有问题。 将生成与当前提案完全相同的代码
x = try(foo(...)) y = try(bar(...))
这只是不同的语法，而不是语义。
````

我想我对它做了一些我不应该做的假设，尽管它仍然存在一些缺点。

如果 foo 或 bar 不返回错误怎么办，它们也可以放在 try 上下文中吗？ 如果不是，那么在错误函数和非错误函数之间切换似乎有点难看，如果可以，那么我们回到旧语言中的 try 块问题。

第二件事是，通常keyword ( ... )语法意味着您在每行添加关键字前缀。 因此对于 import、var、const 等：每一行都以关键字开头。 对该规则做出例外似乎不是一个好的决定

使用特殊标识符而不是使用函数会更惯用吗？

我们已经有了忽略值的空白标识符_ 。
我们可以有类似#的东西，它只能用在最后一个返回值为 error 的函数中。

func foo() (error) {
    f, # := os.Open()
    defer f.Close()
    _, # = f.WriteString("foo")
    return nil
}

当错误分配给#时，函数会立即返回收到的错误。 至于其他变量，它们的值将是：

• 如果它们没有被命名为零值
• 分配给命名变量的值，否则

@deanveloper ， try块语义仅对返回错误值且未分配错误值的函数很重要。 所以本提案的最后一个例子也可以写成
try(x = foo(...)) try(y = bar(...))
将两个语句放在同一个块中类似于我们对重复的import 、 const和var语句所做的操作。

现在，如果你有，例如
try( x = foo(...)) go zee(...) defer fum() y = bar(...) )
这相当于写
try(x = foo(...)) go zee(...) defer fum() try(y = bar(...))
在一个 try 块中考虑所有这些可以减少它的忙碌。

考虑
try(x = foo())
如果 foo() 没有返回错误值，这相当于
x = foo()

考虑
try(f, _ := os.open(filename))
由于返回的错误值被忽略，这相当于只是
f, _ := os.open(filename)

考虑
try(f, err := os.open(filename))
由于返回的错误值没有被忽略，这相当于
f, err := os.open(filename) if err != nil { return ..., err }
正如提案中目前规定的那样。

而且它也很好地整理了嵌套尝试！

这是我上面提到的替代提案的链接：

• https://github.com/golang/go/issues/32473

它要求添加两 (2) 个小型但通用的语言功能，以解决与try()相同的用例

1. 能够在赋值语句中调用func /closure。
2. 能够break 、 continue或return超过一级。

有了这两个特性，它们就没有“魔法”了，我相信它们的使用会产生更容易理解的 Go 代码，并且更符合我们都熟悉的惯用 Go 代码。

我已经阅读了该提案，并且非常喜欢尝试的发展方向。

考虑到尝试的流行程度，我想知道将其设置为更默认的行为是否会使其更易于处理。

考虑地图。 这是有效的：

v := m[key]

就像这样：

v, ok := m[key]

如果我们完全按照 try 建议的方式处理错误，但删除内置函数会怎样。 所以如果我们开始：

v, err := fn()

而不是写：

v := try(fn())

我们可以改为：

v := fn()

当 err 值未被捕获时，它的处理方式与 try 完全相同。 需要一点时间来适应，但感觉与v, ok := m[key]和v, ok := x.(string)非常相似。 基本上，任何未处理的错误都会导致函数返回并设置错误值。

回到设计文档的结论和实现要求：

• 保留语言语法，不引入新关键字
• 它仍然是像try 一样的语法糖，希望很容易解释。
• 不需要新语法
• 它应该完全向后兼容。

我想这将具有与 try 几乎相同的实现要求，因为主要区别不是内置触发语法糖，现在是缺少 err 字段。

因此，使用提案中的CopyFile示例以及defer fmt.HandleErrorf(&err, "copy %s %s", src, dst) ，我们得到：

func CopyFile(src, dst string) (err error) {
        defer fmt.HandleErrorf(&err, "copy %s %s", src, dst)

        r := os.Open(src)
        defer r.Close()

        w := os.Create(dst)
        defer func() {
                err := w.Close()
                if err != nil {
                        os.Remove(dst) // only if a “try” fails
                }
        }()

        io.Copy(w, r)
        w.Close()
        return nil
}

@savaki我喜欢这个并且正在考虑如何通过默认情况下始终处理错误并让程序员指定何时不这样做（通过将错误捕获到变量中）来使 Go 翻转错误处理，但完全没有任何标识符会使代码难以遵循，因为无法看到所有返回点。 可能是命名可能以不同方式返回错误的函数的约定（例如大写公共标识符）。 可能是如果函数返回错误，它必须始终以?结尾。 然后 Go 总是可以隐式处理错误并像 try 一样自动将其返回给调用函数。 这使得它与一些建议使用?标识符而不是 try 的建议非常相似，但重要的区别是这里?将是函数名称的一部分，而不是附加标识符。 实际上，如果没有后缀? ，返回error作为最后一个返回值的函数甚至不会编译。 当然?是任意的，可以用任何其他使意图更明确的东西来代替。 operation?()将等效于包装try(someFunc())但?将是函数名称的一部分，其唯一目的是表明该函数可以像大写一样返回错误变量的第一个字母。

这表面上最终与其他要求将try替换为?的提案非常相似，但一个关键的区别是它使错误处理隐式（自动），而不是使忽略（或包装）错误显式无论如何，这是一种最佳实践。 当然，最明显的问题是它不向后兼容，我相信还有更多。

也就是说，我很想看看 Go 如何通过自动化处理默认/隐式情况的错误，并让程序员编写一些额外的代码来忽略/覆盖处理。 我认为的挑战是如何在这种情况下使所有返回点变得明显，因为如果没有它，错误将变得更像异常，因为它们可能来自任何地方，因为程序的流程不会使其变得明显。 可以说，用视觉指示器隐含错误与实现try并使errcheck编译器失败是一样的。

我们可以用装饰器为旧函数做一些类似 c++ 异常的事情吗？

func some_old_test() (int, error){
    return 0, errors.New("err1")
}
func some_new_test() (int){
        if true {
             return 1
        }
    throw errors.New("err2")
}
func throw_res(int, e error) int {
    if e != nil {
        throw e
    }
    return int
}
func main() {
    fmt.Println("Hello, playground")
    try{
        i := throw_res(some_old_test())
        fmt.Println("i=", i + some_new_test())
    } catch(err io.Error) {
        return err
    } catch(err error) {
        fmt.Println("unknown err", err)
    }
}

@owais我在想语义将与 try 完全相同，因此至少您需要声明 err 类型。 所以如果我们开始：

func foo() error {
  _, err := fn() 
  if err != nil {
    return err
  }

  return nil
} 

如果我理解 try 建议，只需执行以下操作：

func foo() error {
  _  := fn() 
  return nil
} 

不会编译。 一个不错的好处是它使编译有机会告诉用户缺少什么。 大意是使用隐式错误处理需要将错误返回类型命名为 err。

那么，这将起作用：

func foo() (err error) {
  _  := fn() 
  return nil
} 

为什么不只处理未分配给变量的错误的情况。

• 消除对命名返回的需求，编译器可以自己完成这一切。
• 允许添加上下文。
• 处理常见的用例。
• 向后兼容
• 不会与延迟、循环或开关进行奇怪的交互。

if err != nil 情况下的隐式返回，如果程序员无法访问，编译器可以为返回生成局部变量名称。
从代码可读性的角度来看，我个人不喜欢这种特殊情况

f := os.Open("foo.txt")

更喜欢显式返回，遵循代码比书面口头禅

f := os.Open("foo.txt") else return

有趣的是，我们可以接受这两种形式，并让 gofmt 自动添加 else 返回。

添加上下文，也是变量的本地命名。 return 变得明确，因为我们想添加上下文。

f := os.Open("foo.txt") else err {
  return errors.Wrap(err, "some context")
}

添加具有多个返回值的上下文

f := os.Open("foo.txt") else err {
  return i, j, errors.Wrap(err, "some context")
}

嵌套函数要求外部函数以相同的顺序处理所有结果
减去最终误差。

bits := ioutil.ReadAll(os.Open("foo")) else err {
  // either error ends up here.
  return i, j, errors.Wrap(err, "some context")
}

由于函数中缺少错误返回值，编译器拒绝编译

func foo(s string) int {
   i := strconv.Atoi(s) // cannot implicitly return error due to missing error return value for foo.
   return i * 2
}

愉快地编译，因为错误被明确忽略。

func foo(s string) int {
   i, _ := strconv.Atoi(s)
   return i * 2
} 

编译器很高兴。 它会像当前一样忽略错误，因为没有分配或后缀发生。

func foo() error {
  return errors.New("whoops")
}

func bar() {
  foo()
}

在循环中，您可以使用 continue。

for _, s := range []string{"1","2","3","4","5","6"} {
  i := strconv.Atoi(s) else continue
}

编辑：将;替换为else

@savaki我想我理解了你的原始评论，我喜欢 Go 默认处理错误的想法，但我认为如果不添加一些额外的语法更改是不可行的，一旦我们这样做，它就会与当前的提议惊人地相似。

您提出的最大缺点是它没有公开函数可以返回的所有点，这与当前的if err != nil {return err}或此提案中引入的 try 函数不同。 即使它在引擎盖下的功能完全相同，但在视觉上代码看起来会非常不同。 阅读代码时，无法知道哪些函数调用可能会返回错误。 这最终会比 IMO 例外情况更糟糕。

如果编译器强制对可能返回错误的函数进行一些语义约定，则错误处理可能会被隐式处理。 就像他们必须以某个短语或字符开头或结尾一样。 这将使所有返回点都非常明显，我认为它比手动错误处理要好，但不确定考虑到已经有 lint 检查在发现错误被忽略时会发出负载，这会好得多。 看看编译器是否可以根据函数是否返回可能的错误来强制以某种方式命名函数，这将是非常有趣的。

这种方法的主要缺点是需要命名错误结果参数，这可能导致 API 不太美观（但请参阅有关此主题的常见问题解答）。 我们相信，一旦这种风格建立起来，我们就会习惯它。

不确定以前是否有人建议过这样的事情，在这里或提案中找不到。 您是否考虑过另一个返回指向当前函数错误返回值的指针的内置函数？
例如：

func example() error {
        var err *error = funcerror() // always return a non-nil pointer
        fmt.Print(*err) // always nil if the return parameters are not named and not in a defer

        defer func() {
                err := funcerror()
                fmt.Print(*err) // "x"
        }

        return errors.New("x")
}

func exampleNamed() (err error) {
        funcErr := funcerror()
        fmt.Print(*funcErr) // "nil"

        err = errors.New("x")
        fmt.Print(*funcErr) // "x", named return parameter is reflected even before return is called

        *funcErr = errors.New("y")
        fmt.Print(err) // "y", unfortunate side effect?

        defer func() {
                funcErr := funcerror()
                fmt.Print(*funcErr) // "z"
                fmt.Print(err) // "z"
        }

        return errors.New("z")
}

尝试使用：

func CopyFile(src, dst string) (error) {
        defer func() {
                err := funcerror()
                if *err != nil {
                        *err = fmt.Errorf("copy %s %s: %v", src, dst, err)
                }
        }()
        // one liner alternative
        // defer fmt.HandleErrorf(funcerror(), "copy %s %s", src, dst)

        r := try(os.Open(src))
        defer r.Close()

        w := try(os.Create(dst))
        defer func() {
                w.Close()
                err := funcerror()
                if *err != nil {
                        os.Remove(dst) // only if a “try” fails
                }
        }()

        try(io.Copy(w, r))
        try(w.Close())
        return nil
}

或者，如果没有在 defer 中调用 funcerror （名称是一个正在进行的工作 :D ）可能会返回 nil。

另一种选择是 funcerror 返回一个“Errorer”接口以使其只读：

type interface Errorer() {
        Error() error
}

@savaki我实际上确实喜欢您的建议，即省略try()并让它更像是测试地图或类型断言。 这感觉更像_“Go-like。”_

但是，我仍然看到一个明显的问题，那就是您的建议假定使用这种方法的所有错误都会触发return并离开该功能。 它没有考虑的是从当前的for中发出break #$ 或为当前的for continue

早期的return是一把大锤，很多时候手术刀是更好的选择。

所以我断言break和continue应该被允许是有效的错误处理策略，目前你的提议只假定return而try()假定或调用错误处理程序本身只能return ，而不是break或continue 。

看起来 savaki 和我有类似的想法，如果需要，我只是添加了块语义来处理错误。 例如添加 comtext，用于要短路的循环等

@mikeschinkel看到我的扩展，他和我有类似的想法，我只是用一个可选的块语句扩展它

@詹姆斯-劳伦斯

@mikesckinkel看到我的扩展，他和我有相似的想法，我只是用一个可选的块语句扩展它

以你为例：

f := os.Open("foo.txt"); err {
  return errors.Wrap(err, "some context")
}

与我们今天所做的相比：

f,err := os.Open("foo.txt"); 
if err != nil {
  return errors.Wrap(err, "some context")
}

绝对比我更可取。 除了它有几个问题：

1. err似乎是_“神奇地”_声明的。 魔法应该被最小化，不是吗？ 所以让我们声明它：

f, err := os.Open("foo.txt"); err {
  return errors.Wrap(err, "some context")
}

1. 但这仍然行不通，因为 Go 不会将nil值解释为false也不会将指针值解释为true ，所以它需要是：

f, err := os.Open("foo.txt"); err != nil {
  return errors.Wrap(err, "some context")
}

什么是有效的，它开始感觉就像一行一样多的工作和大量的语法，所以为了清晰起见，我可能会继续使用旧方法。

但是如果 Go 添加了两 (2) 个内置函数呢？ iserror()和error() ？ 然后我们可以这样做，这对我来说并没有那么糟糕：

f := os.Open("foo.txt"); iserror() {
  return errors.Wrap(error(), "some context")
}

或者更好_（类似）：_

f := os.Open("foo.txt"); iserror() {
  return error().Extend("some context")
}

你和其他人怎么看？

顺便说一句，检查我的用户名拼写。 如果我不注意的话，我就不会收到你提到的通知......

@mikeschinkel对我在手机上的名字感到抱歉，而 github 没有自动建议。

err 似乎是“神奇地”声明的。 魔法应该被最小化，不是吗？ 所以让我们声明它：

嗯，自动插入返回的整个想法很神奇。 这几乎不是整个提案中最神奇的事情。 另外，我认为错误已被宣布； 就在作用域块上下文的最后，防止它污染父作用域，同时仍然保持我们使用 if 语句通常得到的所有好东西。

对于即将添加到错误包中的 go 错误处理，我通常非常满意。 我认为该提案中的任何内容都不是超级有用的。 如果我们下定决心，我只是试图为 golang 提供最自然的匹配。

_“自动插入返回的整个想法很神奇。”_

你不会从我那里得到任何争论。

_“这几乎不是整个提案中最神奇的事情。”_

我想我试图争辩说_“所有魔法都是有问题的。”_

_“另外我认为错误已被声明；就在作用域块的上下文中的最后......”_

因此，如果我想将其命名为err2这也可以吗？

f := os.Open("foo.txt"); err2 {
  return errors.Wrap(err, "some context")
}

因此，我假设您还建议对分号后的err / err2进行特殊处理，即假定它是nil或不是nil而不是像查看地图时的bool ？

if _,ok := m[a]; !ok {
   print("there is no 'a' in 'm'")
}

对于即将添加到错误包中的 go 错误处理，我通常非常满意。

当与break和continue _( 但不是return结合使用时，我也对错误处理感到满意。)_

事实上，我认为这个try()提案有害多于有用，并且宁愿看到这个实施方案。 #jmtcw。

@beoran @mikeschinkel早些时候我建议我们不能使用泛型实现这个版本的try ，因为它改变了控制流。 如果我没看错，你们都建议我们可以通过调用panic来使用泛型来实现try #$ 。 但是这个版本的try非常明确地没有panic 。 所以我们不能使用泛型来实现这个版本的try 。

是的，我们可以使用泛型（泛型版本比 https://go.googlesource.com/proposal/+/master/design/go2draft-contracts.md 中的设计草案更强大）来编写函数对错误感到恐慌。 但是对错误感到恐慌并不是 Go 程序员今天写的那种错误处理，而且对我来说这似乎不是一个好主意。

@mikeschinkel特殊处理是该块仅在出现错误时执行。
```
f := os.Open('foo'); err { return err } // err 在这里总是非零。

@ianlancetaylor

_“是的，我们可以使用泛型......但是对错误感到恐慌并不是 Go 程序员今天编写的那种错误处理，对我来说这似乎不是一个好主意。”_

我实际上非常同意你的观点，因此看来你可能误解了我评论的意图。 我根本没有建议 Go 团队使用panic()来实现错误处理——当然不是。

相反，我试图从您过去对其他问题的许多评论中实际效仿您，并建议我们避免对 Go 进行任何并非绝对必要的更改，因为它们在 userland 中是可能的。 所以 _if_ 泛型被解决了 _then_ 想要try()的人实际上可以自己实现它，尽管通过利用panic() 。 这将是团队需要为 Go 添加和记录的一项功能。

我没有做的——也许这不是很清楚——提倡人们实际上使用panic()来实现try() ，只要他们真的愿意，他们就可以这样做，并且他们具有以下特性仿制药。

这说明清楚了吗？

对我来说，调用panic与try的提案完全不同。 因此，尽管我认为我理解您在说什么，但我不同意它们是等效的。 即使我们有足够强大的泛型来实现一个恐慌的try版本，我认为对于这个提案中提出的try版本仍然有合理的需求。

@ianlancetaylor 已确认。 同样，我在寻找不需要添加try()的原因，而不是找到添加它的方法。 正如我上面所说，我宁愿没有任何新的错误处理，也不愿有这里建议的try() 。

我个人更喜欢早期的check提案，基于纯粹的视觉方面； check与try() #$ 具有相同的功能，但bar(check foo())对我来说比bar(try(foo()))更具可读性（我只需要一秒钟来计算括号！）。

更重要的是，我对handle / check的主要抱怨是它不允许以不同的方式包装个人支票——现在这个try()提案有同样的缺陷，同时调用延迟和命名返回的棘手的很少使用的新手混淆功能。 至少有了handle ，我们可以选择使用作用域来定义句柄块，而使用defer甚至这是不可能的。

就我而言，这个提案在各个方面都输给了之前的handle / check提案。

这是使用 defers 进行错误处理的另一个问题。

try是函数的受控/有意退出。 defers 始终运行，包括函数的不受控制/意外退出。 这种不匹配可能会导致混乱。 这是一个想象的场景：

func someHTTPHandlerGuts() (err error) {
  defer func() {
    recordMetric("db call failed")
    return fmt.HandleErrorf("db unavailable: %v", err)
  }()
  data := try(makeDBCall)
  // some code that panics due to a bug
  return nil
}

回想一下 net/http 从恐慌中恢复，并想象围绕恐慌调试生产问题。 您会查看您的仪器，并从recordMetric调用中看到数据库调用失败的峰值。 这可能掩盖了真正的问题，即下一行中的恐慌。

我不确定这在实践中有多严重，但（遗憾的是）可能是另一个理由认为 defer 不是错误处理的理想机制。

以下是可能有助于解决所提出的一些问题的修改：将try视为goto而不是return 。 听我说。 :)

try将改为语法糖：

t1, … tn, te := f()  // t1, … tn, te are local (invisible) temporaries
if te != nil {
        err = te   // assign te to the error result parameter
        goto error // goto "error" label
}
x1, … xn = t1, … tn  // assignment only if there was no error

好处：

• defer不需要修饰错误。 （不过，仍然需要命名返回。）
• error:标签的存在是函数中某处存在try的视觉线索。

这也提供了一种添加处理程序的机制，可以避免处理程序作为函数的问题：使用标签作为处理程序。 try(fn(), wrap)将goto wrap而不是goto error 。 编译器可以确认函数中存在wrap: 。 请注意，拥有处理程序也有助于调试：您可以添加/更改处理程序以提供调试路径。

示例代码：

func CopyFile(src, dst string) (err error) {
    r := try(os.Open(src))
    defer r.Close()

    w := try(os.Create(dst))
    defer func() {
        w.Close()
        if err != nil {
            os.Remove(dst) // only if a “try” fails
        }
    }()

    try(io.Copy(w, r), copyfail)
    try(w.Close())
    return nil

error:
    return fmt.Errorf("copy %s %s: %v", src, dst, err)

copyfail:
    recordMetric("copy failure") // count incidents of this failure
    return fmt.Errorf("copy %s %s: %v", src, dst, err)
}

其他的建议：

• 我们可能希望要求用作try目标的任何标签前面都有一个终止语句。 在实践中，这将迫使他们结束函数，并可能阻止一些意大利面条代码。 另一方面，它可能会阻止一些合理、有用的用途。
• try可用于创建循环。 我认为这属于“如果疼就不要做”的旗帜，但我不确定。
• 这需要修复https://github.com/golang/go/issues/26058。

信用：我相信这个想法的一个变体是@griesemer 去年在GopherCon亲自提出的。

@josharian考虑与panic的交互在这里很重要，我很高兴你提出来，但你的例子对我来说似乎很奇怪。 在下面的代码中，延迟总是记录"db call failed"指标对我来说没有意义。 如果someHTTPHandlerGuts成功并返回nil ，这将是一个错误的指标。 defer在所有退出情况下运行，而不仅仅是错误或恐慌情况，因此即使没有恐慌，代码也似乎是错误的。

func someHTTPHandlerGuts() (err error) {
  defer func() {
    recordMetric("db call failed")
    return fmt.HandleErrorf("db unavailable: %v", err)
  }()
  data := try(makeDBCall)
  // some code that panics due to a bug
  return nil
}

@josharian是的，这或多或少正是我们去年讨论的版本（除了我们使用check而不是try ）。 我认为，一旦我们处于error标签处，就不能“跳回”到函数体的其余部分，这一点至关重要。 这将确保goto有点“结构化”（不可能有意大利面条代码）。 提出的一个问题是错误处理程序（ error: ）标签总是会出现在函数的末尾（否则必须以某种方式绕过它）。 就个人而言，我喜欢错误处理代码（最后），但其他人认为它应该在一开始就可见。

@mikeshenkel我认为从循环返回是一个加号而不是负面的。 我的猜测是，这将鼓励开发人员要么使用单独的函数来处理循环的内容，要么像我们目前所做的那样显式使用 err。 这两个对我来说似乎都是不错的结果。

从我的 POV 来看，我不觉得这种 try 语法必须处理每个用例，就像我觉得我不需要使用

V，好的：= m[键]

从地图读取形成

您可以通过以简化形式恢复handle / check提议来避免 goto 标签强制处理程序到函数末尾。 如果我们使用handle err { ... }语法但只是不让处理程序链接，而是只使用最后一个会怎样。 它大大简化了该提议，并且与 goto 的想法非常相似，除了它使处理更接近使用点。

func CopyFile(src, dst string) (err error) {
    handle err {
        return fmt.Errorf("copy %s %s: %v", src, dst, err)
    }
    r := check os.Open(src)
    defer r.Close()

    w := check os.Create(dst)
    defer func() {
        w.Close()
        if err != nil {
            os.Remove(dst) // only if a “check” fails
        }
    }()

    {
        // handlers are scoped, after this scope the original handle is used again.
        // as an alternative, we could have repeated the first handle after the io.Copy,
        // or come up with a syntax to name the handlers, though that's often not useful.
        handle err {
            recordMetric("copy failure") // count incidents of this failure
            return fmt.Errorf("copy %s %s: %v", src, dst, err)
        }
        check io.Copy(w, r)
    }
    check w.Close()
    return nil
}

作为奖励，这有一条让处理程序链接的未来路径，因为所有现有的使用都会有回报。

@josharian @griesemer如果您引入命名处理程序（许多对检查/处理请求的响应，请参阅重复主题），有语法选项比try(f(), err)更可取：

try.err f()
try?err f()
try#err f()

?err    f() // because 'try' is redundant
?return f() // no handler
?panic  f() // no handler

(?err f()).method()

f?err() // lead with function name, instead of error handling
f?err().method()

file, ?err := os.Open(...) // many check/handle responses also requested this style

我最喜欢 Go 的一件事是它的语法相对没有标点符号，并且可以大声朗读而不会出现大问题。 我真的很讨厌 Go 最终成为$#@!perl 。

对我来说，将“尝试”作为内置功能并启用链有两个问题：

• 它与 go 中的其余控制流不一致（例如，for/if/return/etc 关键字）。
• 它使代码的可读性降低。

我宁愿让它成为一个不带括号的声明。 提案中的示例需要多行，但会变得更具可读性（即，单个“尝试”实例将更难遗漏）。 是的，它会破坏外部解析器，但我更喜欢保持一致性。

三元运算符是另一个地方，go 没有东西，需要更多的击键，但同时提高了可读性/可维护性。 以这种更受限制的形式添加“尝试”将更好地平衡表达性与可读性，IMO。

FWIW， panic影响控制流并且有括号，但是go和defer也影响流并且不影响流。 我倾向于认为try与defer更相似，因为它是一种不寻常的流程操作，并且使try (try os.Open(file)).Read(buf)更难执行是好的，因为我们想阻止单行无论如何，但无论如何。 哪一个都好。

建议每个人都会讨厌最终错误返回变量的隐式名称： $err 。 它比try() IMO 更好。 :-)

@griesemer

_“就个人而言，我喜欢错误处理代码（最后）”_

对此+1！

我发现错误发生_before_执行的错误处理比错误发生_after_执行的错误处理更难推理。 不得不在精神上跳回并强制遵循逻辑流程，感觉就像我回到了 1980 年，用 GOTO 编写 Basic。

让我再次以CopyFile()为例提出另一种处理错误的潜在方法：

func CopyFile(src, dst string) (err error) {

    r := os.Open(src)
    defer r.Close()

    w := os.Create(dst)
    defer w.Close()

    io.Copy(w, r)
    w.Close()

    for err := error {
        switch err.Source() {
        case w.Close:
            os.Remove(dst) // only if a “try” fails
            fallthrough
        case os.Open, os.Create, io.Copy:
            err = fmt.Errorf("copy %s %s: %v", src, dst, err)
        default:
            err = fmt.Errorf("an unexpected error occurred")
        }
    }

    return err
}

所需的语言更改是：

1. 允许for error{}构造，类似于for range{}但仅在错误时输入且仅执行一次。

2. 允许省略捕获实现<object>.Error() string的返回值，但仅当同一func中存在for error{}构造时。

3. 当func在其最后一个返回值中返回 _"error"_ 时，导致程序控制流跳转到for error{}构造的第一行。

4. 当返回一个 _"error"_ 时，Go 会添加一个对返回错误的函数的引用，该错误应该可以通过<error>.Source()检索

什么是_“错误”_？

目前 _"error"_ 被定义为任何实现Error() string的对象，当然不是nil 。

然而，通常需要扩展错误_even on success_以允许返回 RESTful API 的成功结果所需的值。 所以我会要求 Go 团队不要自动假设err!=nil意味着 _"error"_ 而是检查错误对象是否实现IsError()以及IsError()是否返回true之前假设任何非nil值是一个_“错误”。

_（我不一定是在谈论标准库中的代码，但主要是如果您选择控制流在_“错误”_上进行分支。如果您只看err!=nil ，我们将非常有限可以根据我们函数中的返回值来做。）_

顺便说一句，让每个人都可以通过添加一个新的内置iserror()函数来以同样的方式测试 _"error"_ ：

type ErrorIser interface {
    IsError() bool
}
func iserror(err error) bool {
    if err == nil { 
        return false
    }
    if _,ok := err.(ErrorIser); !ok {
        return true
    }
    return err.IsError()
}

允许不捕获_“错误”_的一个附带好处

请注意，允许从func调用中不捕获最后一个 _"error"_ 将允许以后的重构从最初不需要返回错误的func中返回错误。 并且它将允许这种重构而不会破坏任何使用这种形式的错误恢复和调用的现有代码func s。

对我来说，“我应该返回错误还是放弃错误处理以简化调用？”的决定是我在编写 Go 代码时最大的困惑之一。 允许不捕获上述_“错误”_几乎可以消除这种困境。

大约半年前，我实际上尝试将这个想法作为 Go 翻译器来实现。 我没有强烈的意见是否应该将此功能添加为 Go 内置，但让我分享一下经验（虽然我不确定它是否有用）。

https://github.com/rhysd/trygo

我调用了扩展语言 TryGo 并实现了 TryGo 到 Go 的翻译器。

使用翻译器，代码

func CreateFileInSubdir(subdir, filename string, content []byte) error {
    cwd := try(os.Getwd())

    try(os.Mkdir(filepath.Join(cwd, subdir)))

    p := filepath.Join(cwd, subdir, filename)
    f := try(os.Create(p))
    defer f.Close()

    try(f.Write(content))

    fmt.Println("Created:", p)
    return nil
}

可以翻译成

func CreateFileInSubdir(subdir, filename string, content []byte) error {
    cwd, _err0 := os.Getwd()
    if _err0 != nil {
        return _err0
    }

    if _err1 := os.Mkdir(filepath.Join(cwd, subdir)); _err1 != nil {
        return _err1
    }

    p := filepath.Join(cwd, subdir, filename)
    f, _err2 := os.Create(p)
    if _err2 != nil {
        return _err2
    }
    defer f.Close()

    if _, _err3 := f.Write(content); _err3 != nil {
        return _err3
    }

    fmt.Println("Created:", p)
    return nil
}

由于语言的限制，我无法实现通用的try()调用。 它仅限于

• RHS 定义声明
• 赋值语句的 RHS
• 通话声明

但我可以用我的小项目试试这个。 我的经验是

• 它基本上工作正常并节省了几行
• 命名返回值实际上对于err是不可用的，因为它的函数的返回值是由赋值和try()特殊函数决定的。 很混乱
• 如上所述，此try()函数缺少“包装错误”功能。

_“这两个对我来说似乎都是好的结果。”_

我们将不得不同意在这里不同意。

_“这种尝试语法（不必）处理每个用例”_

那个模因可能是最令人不安的。 至少考虑到 Go 团队/社区对过去不广泛适用的任何变化的抵制程度。

如果我们在这里允许这种理由，为什么我们不能重新审视过去因为不广泛适用而被拒绝的提案？

我们现在是否愿意争论对选定的边缘情况有用的 Go 变化？

在我看来，树立这个先例不会长期产生好的结果......

_“@mikeshenkel”_

PS因为拼写错误，我一开始没有看到你的消息。 _（这不会冒犯我，只是当我的用户名拼写错误时我不会收到通知......）_

我很欣赏对向后兼容性的承诺，这促使您将try设为内置函数，而不是关键字，但在与拥有可以更改控制流的常用函数（ panic和recover非常罕见），我想知道：有没有人对try作为开源代码库中的标识符的频率进行过大规模分析？ 我很好奇和怀疑，所以我对以下内容进行了初步搜索：

• https://github.com/google/go-github
• https://github.com/cockroachdb/cockroach
• https://github.com/golang/net
• https://github.com/exercism/xgo
• https://github.com/GoogleCloudPlatform/kubernetes
• https://github.com/syncthing/syncthing
• https://github.com/mitchellh/packer
• https://github.com/drone/drone
• https://github.com/coreos/etcd
• https://github.com/docker/docker
• https://github.com/sjwhitworth/golearn
• https://github.com/bitly/nsq
• https://github.com/smartystreets/goconvey
• https://github.com/golang/tools
• https://github.com/coreos/fleet
• https://github.com/limetext/lime
• https://github.com/flynn/flynn
• https://github.com/dropbox/godropbox
• https://github.com/hashicorp/consul
• https://github.com/hashicorp/terraform

在这些存储库中的 11,108,770 条重要的 Go 行中，只有63个try实例被用作标识符。 当然，我意识到这些代码库（虽然很大，被广泛使用，并且本身很重要）只代表了 Go 代码的一小部分，此外，我们无法直接分析私有代码库，但它肯定是一个有趣的结果。

此外，因为try和任何关键字一样是小写的，所以您永远不会在包的公共 API 中找到它。 关键字添加只会影响包内部。

这是我想加入的一些想法的前言，这些想法将从try作为关键字中受益。

我建议以下结构。

1) 没有处理程序

// The existing proposal, but as a keyword rather than builtin.  When an error is 
// "caught", the function returns all zero values plus the error.  Nothing 
// particularly new here.
func doSomething() (int, error) {
    try SomeFunc()
    a, b := try AnotherFunc()

    // ...

    return 123, nil
}

2) 处理程序

请注意，错误处理程序是简单的代码块，旨在内联，而不是函数。 更多关于这下面。

func doSomething() (int, error) {
    // Inline error handler
    a, b := try SomeFunc() else err {
        return 0, errors.Wrap(err, "error in doSomething:")
    }

    // Named error handlers
    handler logAndContinue err {
        log.Errorf("non-critical error: %v", err)
    }
    handler annotateAndReturn err {
        return 0, errors.Wrap(err, "error in doSomething:")
    }

    c, d := try SomeFunc() else logAndContinue
    e, f := try OtherFunc() else annotateAndReturn

    // ...

    return 123, nil
}

建议的限制：

• 你只能try一个函数调用。 没有try err 。
• 如果不指定处理程序，则只能在函数中使用try ，该函数将错误作为最右边的返回值返回。 try基于其上下文的行为方式没有变化。 它从不恐慌（正如线程中前面所讨论的）。
• 没有任何类型的“处理程序链”。 处理程序只是可内联的代码块。

好处：

• try / else语法可以简单地脱糖到现有的“复合 if”中：
  go a, b := try SomeFunc() else err { return 0, errors.Wrap(err, "error in doSomething:") }
  变成
  go if a, b, err := SomeFunc(); err != nil { return 0, errors.Wrap(err, "error in doSomething:") }
  在我看来，复合 if 似乎总是比帮助更令人困惑，原因很简单：条件通常发生在操作之后，并且与处理其结果有关。 如果操作被嵌入到条件语句中，那么它的发生就不太明显了。 眼睛被分散了。 此外，已定义变量的范围并不像它们在一行中最左边时那么明显。
• 错误处理程序有意不被定义为函数（也没有任何类似函数语义的东西）。 这为我们做了几件事：
  
  
  
  • 编译器可以简单地内联一个命名的处理程序，无论它被引用到哪里。 它更像是一个简单的宏/代码生成模板，而不是函数调用。 运行时甚至不需要知道处理程序的存在。
  
  
  • 我们在处理程序内部可以做的事情不受限制。 我们绕过了对check / handle的批评，即“这个错误处理框架只适用于纾困”。 我们还绕过了“处理程序链”的批评。 任何任意代码都可以放置在这些处理程序之一中，并且不暗示其他控制流。
  
  
  • 我们不必在处理程序中劫持return来表示super return 。 劫持关键字非常令人困惑。 return只是意味着return ，并没有真正需要super return 。
  
  
  • defer不需要将月光作为错误处理机制。 我们可以继续认为它主要是清理资源等的一种方式。
  
  
• 关于为错误添加上下文：
  
  
  
  • 使用处理程序添加上下文非常简单，看起来与现有的if err != nil块非常相似
  
  
  • 尽管“try without handler”结构并不直接鼓励添加上下文，但重构为处理程序表单非常简单。 它的预期用途主要是在开发过程中，编写go vet检查以突出未处理的错误将非常简单。
  
  

如果这些想法与其他提议非常相似，我深表歉意——我试图跟上他们的步伐，但可能错过了很多。

@brynbellomy感谢您的关键字分析 - 这是非常有用的信息。 似乎try作为关键字可能没问题。 （您说 API 不受影响 - 这是真的，但try可能仍会显示为参数名称或类似名称 - 因此文档可能必须更改。但我同意这不会影响这些包的客户端。）

关于您的建议：即使没有指定的处理程序，它也可以正常运行，不是吗？ （这将在不损失功率的情况下简化提案。可以简单地从内联处理程序调用本地函数。）

关于您的建议：即使没有指定的处理程序，它也可以正常运行，不是吗？ （这将在不损失功率的情况下简化提案。可以简单地从内联处理程序调用本地函数。）

@griesemer确实——我对包含这些内容感到很冷淡。 如果没有，肯定会更 Go-ish。

另一方面，人们似乎确实希望能够进行单行错误处理，包括return的单行错误处理。 一个典型的例子是日志，然后是return 。 如果我们在else子句中使用本地函数，我们可能会丢失：

a, b := try SomeFunc() else err {
    someLocalFunc(err)
    return 0, err
}

（不过，我仍然更喜欢用这个来复合 if）

但是，您仍然可以通过实现线程前面讨论的简单gofmt调整来获得添加错误上下文的单行返回：

a, b := try SomeFunc() else err { return 0, errors.Wrap(err, "bad stuff!") }

上述提案中是否需要 new 关键字？ 为什么不：

SomeFunc() else return
a, b := SomeOtherFunc() else err { return 0, errors.Wrap(err, "bad stuff!") }

@griesemer如果处理程序重新回到桌面上，我建议您提出一个新问题来讨论 try/handle 或 try/_label_。 这个提议特别省略了处理程序，并且有无数种方法来定义和调用它们。

任何建议处理程序的人都应该首先阅读检查/处理反馈维基。 很有可能你的梦想已经在那里描述了:-)
https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback

@smonkewitz不，在该版本中不需要新的关键字，因为它绑定到赋值语句，到目前为止，在各种语法糖中已经多次提及。

https://github.com/golang/go/issues/32437#issuecomment -499808741
https://github.com/golang/go/issues/32437#issuecomment -499852124
https://github.com/golang/go/issues/32437#issuecomment -500095505

@ianlancetaylor go 团队是否考虑过这种特殊的错误处理方式？ 它不像建议的 try builtin 那样容易实现，但感觉更惯用。 ~不必要的声明，对不起。~

我想重复一下@deanveloper和其他一些人说过的话，但我自己强调。 在https://github.com/golang/go/issues/32437#issuecomment -498939499 @deanveloper说：

try是有条件的回报。 在 Go 中，控制流和返回都被固定在基座上。 函数中的所有控制流都是缩进的，所有返回都以return开头。 将这两个概念混合在一起形成一个容易错过的函数调用，感觉有点不对劲。

此外，在这个提议中， try是一个返回值的函数，因此它可以用作更大表达式的一部分。

有人认为panic已经为改变控制流的内置函数开创了先例，但我认为panic根本不同，原因有两个：

1. 恐慌不是有条件的； 它总是中止调用函数。
2. Panic 不返回任何值，因此只能作为独立语句出现，这增加了它的可见性。

另一方面尝试：

1. 是有条件的； 它可能会或可能不会从调用函数返回。
2. 返回值并且可以出现在复合表达式中，可能多次出现在一行上，可能超过我的编辑器窗口的右边距。

由于这些原因，我认为try感觉不仅仅是“有点偏离”，我认为它从根本上损害了代码的可读性。

今天，当我们第一次遇到一些 Go 代码时，我们可以快速浏览它以找到可能的退出点和控制流点。 我相信这是 Go 代码的一个非常有价值的属性。 使用try编写缺少该属性的代码变得太容易了。

我承认，重视代码可读性的 Go 开发人员很可能会集中在try的使用习惯上，以避免这些可读性陷阱。 我希望这会发生，因为代码可读性似乎是许多 Go 开发人员的核心价值。 但对我来说， try对现有代码习语增加了足够的价值来承担向语言添加新概念以供每个人学习的重量，这很容易损害可读性，这对我来说并不明显。

````
如果它！=“打破”{
不要修复（它）
}

@ChrisHines对于您的观点（在此线程的其他地方有所回应），让我们添加另一个限制：

• 任何try语句（即使是那些没有处理程序的语句）都必须出现在它自己的行上。

您仍然会从视觉噪音的大幅减少中受益。 然后，您保证了由return注释的返回和由try注释的条件返回，并且这些关键字始终位于行首（或者最坏的情况，直接在变量赋值之后）。

所以，没有这种废话：

try EmitEvent(try (try DecodeMsg(m)).SaveToDB())

而是这个：

dm := try DecodeMsg(m)
um := try dm.SaveToDB()
try EmitEvent(um)

这仍然比这更清楚：

dm, err := DecodeMsg(m)
if err != nil {
    return nil, err
}

um, err := dm.SaveToDB()
if err != nil {
    return nil, err
}

err = EmitEvent(um)
if err != nil {
    return nil, err
}

我喜欢这种设计的一件事是，在不注释可能发生的错误的情况下，不可能默默地忽略错误。 而现在，你有时会看到x, _ := SomeFunc() （什么是忽略的返回值？一个错误？别的东西？），现在你必须清楚地注释：

x := try SomeFunc() else err {}

自从我上一篇支持该提案的帖子以来，我已经看到@jagv （无参数try返回*error ）和@josharian （标记为错误处理程序）发布的两个想法，我相信稍加修改的形式将大大加强该提案。

将这些想法与我自己的另一个想法放在一起，我们将有四个版本的try ：

1. 尝试（）
2. 尝试（参数）
3. 尝试（参数，标签）
4. 尝试（参数，恐慌）

1 将简单地返回一个指向错误返回参数 (ERP) 的指针，如果没有返回参数 (ERP)，则返回 nil (仅 #4)。 这将提供命名 ERP 的替代方案，而无需添加进一步的插件。

2 将完全按照目前的设想工作。 将立即返回一个非零错误，但可以用defer语句修饰。

3 将按照@josharian的建议工作，即在出现非零错误时，代码将分支到标签。 但是，不会有默认的错误处理程序标签，因为这种情况现在会退化为 #2。

在我看来，与defer相比，这通常是修饰错误（或在本地处理它们然后返回 nil）的更好方法，因为它更简单、更快捷。 任何不喜欢它的人仍然可以使用#2。

最好将错误处理标签/代码放在函数末尾附近，而不是跳回函数体的其余部分。 但是，我认为编译器也不应该强制执行，因为它们可能会在某些奇怪的情况下有用，并且在任何情况下执行都可能很困难。

因此，正常的标签和goto行为会将主题（如@josharian所说）应用于首先修复的#26058，但我认为无论如何都应该修复它。

标签的名称不能是panic ，因为这会与 #4 冲突。

4 将立即panic而不是返回或分支。 因此，如果这是在特定功能中使用的唯一版本的try ，则不需要 ERP。

我已经添加了这个，所以测试包可以像现在一样工作，而不需要进一步的内置或其他更改。 但是，它在其他 _fatal_ 场景中也可能有用。

这需要是try的单独版本，而不是分支到错误处理程序，然后从那里惊慌失措仍然需要 ERP。

对最初提案最强烈的反应之一是担心失去对函数返回的正常流程的轻松可见性。

例如， @deanveloper在https://github.com/golang/go/issues/32437#issuecomment -498932961 中很好地表达了这种担忧，我认为这是这里获得最高评价的评论。

@dominikh在https://github.com/golang/go/issues/32437#issuecomment -499067357 中写道：

在 gofmt'ed 代码中，return 始终匹配 /^\t*return / - 这是一个非常简单的模式，无需任何帮助即可通过肉眼发现。 另一方面，try 可以出现在代码中的任何地方，嵌套在函数调用的任意深处。 再多的培训也不会让我们能够在没有工具帮助的情况下立即发现函数中的所有控制流。

为了解决这个问题， @brynbellomy昨天建议：

任何 try 语句（即使是那些没有处理程序的）都必须出现在它自己的行上。

更进一步， try可能需要作为行的开头，即使对于分配也是如此。

所以它可能是：

try dm := DecodeMsg(m)
try um := dm.SaveToDB()
try EmitEvent(um)

而不是以下内容（来自@brynbellomy的示例）：

dm, err := DecodeMsg(m)
if err != nil {
    return nil, err
}

um, err := dm.SaveToDB()
if err != nil {
    return nil, err
}

err = EmitEvent(um)
if err != nil {
    return nil, err
}

即使没有任何编辑器或 IDE 帮助，它似乎也会保留相当多的可见性，同时仍然减少样板文件。

这可以与当前提出的依赖于命名结果参数的基于延迟的方法一起使用，或者它可以与指定正常的处理函数一起使用。 （在我看来，在不需要命名返回值的情况下指定处理函数似乎比要求命名返回值更好，但这是一个单独的点）。

该提案包括以下示例：

info := try(try(os.Open(file)).Stat())    // proposed try built-in

那可能是：

try f := os.Open(file)
try info := f.Stat()

与今天有人可能写的相比，这仍然是样板代码的减少，即使不像建议的语法那么短。 也许那会足够短？

@elagergren-spideroak 提供了这个例子：

try(try(try(to()).parse().this)).easily())

我认为这有不匹配的括号，这可能是一个深思熟虑的观点或一点点幽默，所以我不确定该示例是否打算使用 2 try或 3 try 。 无论如何，最好将其分布在以try开头的 2-3 行中。

@thepudds ，这就是我在之前的评论中得到的。 除了给定的

try f := os.Open(file)
try info := f.Stat()

一件显而易见的事情是将try视为一个try 块，其中可以将多个句子放在括号内。 所以上面可以变成

try (
    f := os.Open(file)
    into := f.Stat()
)

如果编译器知道如何处理这个问题，同样的事情也适用于嵌套。 所以现在上面可以变成

try info := os.Open(file).Stat()

从函数签名中，编译器知道 Open 可以返回一个错误值，并且由于它在 try 块中，它需要生成错误处理，然后在主要返回值上调用 Stat() 等等。

接下来是允许没有生成错误值或在本地处理的语句。 所以你现在可以说

try (
    f := os.Open(file)
    debug("f: %v\n", f) // debug returns nothing
    into := f.Stat()
)

这允许在不重新排列 try 块的情况下进化代码。 但是出于某种奇怪的原因，人们似乎认为必须明确说明错误处理！ 他们要

try(try(try(to()).parse()).this)).easily())

虽然我很好

try to().parse().this().easily()

即使在这两种情况下都可以生成完全相同的错误检查代码。 我的观点是，如果需要，您始终可以编写特殊代码来处理错误。 try （或任何你喜欢的名字）只是简单地整理默认的错误处理（即把它扔给调用者）。

另一个好处是，如果编译器生成默认错误处理，它可以添加更多识别信息，以便您知道上面四个函数中的哪个函数失败了。

我有点担心try出现在其他表达式中的程序的可读性。 所以我在标准库上运行grep "return .*err$"并开始随机读取块。 有 7214 个结果，我只看了几百个。

首先要注意的是，在try应用的地方，它使几乎所有这些块都更具可读性。

第二件事是，其中很少有人（不到十分之一）会将try放入另一个表达式中。 典型情况是x := try(...)或^try(...)$形式的语句。

下面是一些示例，其中try会出现在另一个表达式中：

文本/模板

func gt(arg1, arg2 reflect.Value) (bool, error) {
        // > is the inverse of <=.
        lessOrEqual, err := le(arg1, arg2)
        if err != nil {
                return false, err
        }
        return !lessOrEqual, nil
}

变成：

func gt(arg1, arg2 reflect.Value) (bool, error) {
        // > is the inverse of <=.
        return !try(le(arg1, arg2)), nil
}

文本/模板

func index(item reflect.Value, indices ...reflect.Value) (reflect.Value, error) {
...
        switch v.Kind() {
        case reflect.Map:
                index, err := prepareArg(index, v.Type().Key())
                if err != nil {
                        return reflect.Value{}, err
                }
                if x := v.MapIndex(index); x.IsValid() {
                        v = x
                } else {
                        v = reflect.Zero(v.Type().Elem())
                }
        ...
        }
}

变成

func index(item reflect.Value, indices ...reflect.Value) (reflect.Value, error) {
        ...
        switch v.Kind() {
        case reflect.Map:
                if x := v.MapIndex(try(prepareArg(index, v.Type().Key()))); x.IsValid() {
                        v = x
                } else {
                        v = reflect.Zero(v.Type().Elem())
                }
        ...
        }
}

（这是我看到的最有问题的例子）

正则表达式/语法：

regexp/syntax/parse.go

func Parse(s string, flags Flags) (*Regexp, error) {
        ...
        if c, t, err = nextRune(t); err != nil {
                return nil, err
        }
        p.literal(c)
        ...
}

变成

func Parse(s string, flags Flags) (*Regexp, error) {
        ...
        c, t = try(nextRune(t))
        p.literal(c)
        ...
}

这不是在另一个表达式中尝试的例子，但我想把它叫出来，因为它提高了可读性。 在这里更容易看出c和t的值超出了 if 语句的范围。

网络/http

网络/http/request.go:readRequest

        mimeHeader, err := tp.ReadMIMEHeader()
        if err != nil {
                return nil, err
        }
        req.Header = Header(mimeHeader)

变成：

        req.Header = Header(try(tp.ReadMIMEHeader())

数据库/sql

        if driverCtx, ok := driveri.(driver.DriverContext); ok {
                connector, err := driverCtx.OpenConnector(dataSourceName)
                if err != nil {
                        return nil, err
                }
                return OpenDB(connector), nil
        }

变成

        if driverCtx, ok := driveri.(driver.DriverContext); ok {
                return OpenDB(try(driverCtx.OpenConnector(dataSourceName))), nil
        }

数据库/sql

        si, err := ctxDriverPrepare(ctx, dc.ci, query)
        if err != nil {
                return nil, err
        }
        ds := &driverStmt{Locker: dc, si: si}

变成

        ds := &driverStmt{
                Locker: dc,
                si: try(ctxDriverPrepare(ctx, dc.ci, query)),
        }

网络/http

        if http2isconnectioncloserequest(req) && dialonmiss {
                // it gets its own connection.
                http2tracegetconn(req, addr)
                const singleuse = true
                cc, err := p.t.dialclientconn(addr, singleuse)
                if err != nil {
                        return nil, err
                }
                return cc, nil
        }

变成

        if http2isconnectioncloserequest(req) && dialonmiss {
                // it gets its own connection.
                http2tracegetconn(req, addr)
                const singleuse = true
                return try(p.t.dialclientconn(addr, singleuse))
        }

网络/http

func (f *http2Framer) endWrite() error {
        ...
        n, err := f.w.Write(f.wbuf)
        if err == nil && n != len(f.wbuf) {
                err = io.ErrShortWrite
        }
        return err
}

变成

func (f *http2Framer) endWrite() error {
        ...
        if try(f.w.Write(f.wbuf) != len(f.wbuf) {
                return io.ErrShortWrite
        }
        return nil
}

（这个我真的很喜欢。）

网络/http

        if f, err := fr.ReadFrame(); err != nil {
                return nil, err
        } else {
                hc = f.(*http2ContinuationFrame) // guaranteed by checkFrameOrder
        }

变成

        hc = try(fr.ReadFrame()).(*http2ContinuationFrame)// guaranteed by checkFrameOrder

}

（也不错。）

净：

        if ctrlFn != nil {
                c, err := newRawConn(fd)
                if err != nil {
                        return err
                }
                if err := ctrlFn(fd.ctrlNetwork(), laddr.String(), c); err != nil {
                        return err
                }
        }

变成

        if ctrlFn != nil {
                try(ctrlFn(fd.ctrlNetwork(), laddr.String(), try(newRawConn(fd))))
        }

也许这太多了，而应该是：

        if ctrlFn != nil {
                c := try(newRawConn(fd))
                try(ctrlFn(fd.ctrlNetwork(), laddr.String(), c))
        }

总的来说，我非常喜欢try对我阅读的标准库代码的影响。

最后一点：看到try应用于阅读提案中的几个示例之外的代码是很有启发性的。 我认为值得考虑编写一个工具来自动转换代码以使用try （它不会改变程序的语义）。 阅读一个针对 github 上的流行包产生的差异样本会很有趣，看看我在标准库中找到的内容是否成立。 这样一个程序的输出可以为提案的效果提供额外的洞察力。

@crawshaw感谢您这样做，很高兴看到它在行动。 但是看到它的实际效果让我更加认真地对待我之前一直在驳斥的反对内联错误处理的论点。

由于这与@thepudds将try设为语句的有趣建议非常接近，因此我使用该语法重写了所有示例，发现它比表达式 - try或现状，不需要太多额外的行：

func gt(arg1, arg2 reflect.Value) (bool, error) {
        // > is the inverse of <=.
        try lessOrEqual := le(arg1, arg2)
        return !lessOrEqual, nil
}

func index(item reflect.Value, indices ...reflect.Value) (reflect.Value, error) {
        ...
        switch v.Kind() {
        case reflect.Map:
                try index := prepareArg(index, v.Type().Key())
                if x := v.MapIndex(index); x.IsValid() {
                        v = x
                } else {
                        v = reflect.Zero(v.Type().Elem())
                }
        ...
        }
}

func Parse(s string, flags Flags) (*Regexp, error) {
        ...
        try c, t = nextRune(t)
        p.literal(c)
        ...
}

        try mimeHeader := tp.ReadMIMEHeader()
        req.Header = Header(mimeHeader)

        if driverCtx, ok := driveri.(driver.DriverContext); ok {
                try connector := driverCtx.OpenConnector(dataSourceName)
                return OpenDB(connector), nil
        }

如果有多个字段必须是try -ed，那么这个表达式可能会更好 - try ，但我仍然更喜欢这种权衡的平衡

        try si := ctxDriverPrepare(ctx, dc.ci, query)
        ds := &driverStmt{Locker: dc, si: si}

这基本上是最坏的情况，看起来不错：

        if http2isconnectioncloserequest(req) && dialonmiss {
                // it gets its own connection.
                http2tracegetconn(req, addr)
                const singleuse = true
                try cc := p.t.dialclientconn(addr, singleuse)
                return cc, nil
        }

我与自己争论if try是否合法或应该合法，但我无法给出合理的解释，为什么它不应该合法，并且在这里效果很好：

func (f *http2Framer) endWrite() error {
        ...
        if try n := f.w.Write(f.wbuf); n != len(f.wbuf) {
                return io.ErrShortWrite
        }
        return nil
}

        try f := fr.ReadFrame()
        hc = f.(*http2ContinuationFrame) // guaranteed by checkFrameOrder

        if ctrlFn != nil {
                try c := newRawConn(fd)
                try ctrlFn(fd.ctrlNetwork(), laddr.String(), c)
        }

浏览@crawshaw的示例只会让我更加确定控制流通常会变得足够神秘，以至于对设计更加谨慎。 即使是少量的复杂性也变得难以阅读并且容易出错。 我很高兴看到考虑的选项，但是在这种受保护的语言中使控制流复杂化似乎异常不合时宜。

func (f *http2Framer) endWrite() error {
        ...
        if try(f.w.Write(f.wbuf) != len(f.wbuf) {
                return io.ErrShortWrite
        }
        return nil
}

此外， try不是“尝试”任何东西。 它是一个“保护继电器”。 如果提案的基本语义不正确，那么生成的代码也存在问题我并不感到惊讶。

func (f *http2Framer) endWrite() error {
        ...
        relay n := f.w.Write(f.wbuf)
        return checkShortWrite(n, len(f.wbuf))
}

如果你做一个 try 语句，你可以使用一个标志来指示哪个返回值，以及什么操作：

try c, @      := newRawConn(fd) // return
try c, <strong i="6">@panic</strong> := newRawConn(fd) // panic
try c, <strong i="7">@hname</strong> := newRawConn(fd) // invoke named handler
try c, <strong i="8">@_</strong>     := newRawConn(fd) // ignore, or invoke "ignored" handler if defined

你仍然需要一个子表达式语法（Russ 已经声明这是一个要求），至少对于恐慌和忽略操作。

首先，我赞扬@crawshaw花时间查看大约 200 个真实示例并花时间在上面进行深思熟虑的文章。

其次， @jimmyfrasche ，关于您在此处对http2Framer示例的回复：

我与自己争论if try是否合法或应该合法，但我无法给出合理的解释，为什么它不应该合法，而且在这里效果很好：

```
func (f *http2Framer) endWrite() 错误 {
...
如果尝试 n := fwWrite(f.wbuf); n!= len(f.wbuf) {
返回 io.ErrShortWrite
}
返回零
}

At least under what I was suggesting above in https://github.com/golang/go/issues/32437#issuecomment-500213884, under that proposal variation I would suggest `if try` is not allowed.

That `http2Framer` example could instead be:

func (f *http2Framer) endWrite() 错误 {
...
尝试 n := fwWrite(f.wbuf)
如果 n != len(f.wbuf) {
返回 io.ErrShortWrite
}
返回零
}
`` That is one line longer, but hopefully still "light on the page". Personally, I think that (arguably) reads more cleanly, but more importantly it is easier to see the试试`。

@deanveloper上面在https://github.com/golang/go/issues/32437#issuecomment -498932961 中写道：

从函数返回似乎是一件“神圣”的事情

那个特定的http2Framer示例最终没有尽可能短。 但是，如果try必须是一行中的第一件事，则它保留从更“神圣”的函数返回。

@crawshaw提到：

第二件事是，其中很少有（不到十分之一）会将 try 放在另一个表达式中。 典型的情况是 x := try(...) 或 ^try(...)$ 形式的语句。

也许只用更受限制的形式try来部分帮助 10 个示例中的 1 个是可以的，特别是如果这些示例中的典型案例最终具有相同的行数，即使try是需要成为一条线上的第一件事吗？

@jimmyfrasche

@crawshaw感谢您这样做，很高兴看到它在行动。 但是看到它的实际效果让我更加认真地对待我之前一直在驳斥的反对内联错误处理的论点。

由于这与@thepudds将try设为语句的有趣建议非常接近，因此我使用该语法重写了所有示例，发现它比表达式 - try或现状，不需要太多额外的行：

func gt(arg1, arg2 reflect.Value) (bool, error) {
        // > is the inverse of <=.
        try lessOrEqual := le(arg1, arg2)
        return !lessOrEqual, nil
}

您的第一个示例很好地说明了为什么我强烈喜欢表达式 - try 。 在您的版本中，我必须将调用le的结果放在一个变量中，但该变量没有le术语尚未暗示的语义含义。 所以我不能给它起一个既无意义（如x ）或多余（如lessOrEqual ）的名字。 使用表达式- try ，不需要中间变量，所以这个问题甚至不会出现。

我宁愿不必花费脑力为最好保持匿名的事物发明名称。

我很高兴在try （关键字）已移至行首的最后几篇文章中支持我。 它确实应该与return共享相同的视觉空间。

回复： @jimmyfrasche的建议允许在复合if语句中使用try #$，这正是我认为这里的许多人试图避免的事情，原因如下：

• 它将两种非常不同的控制流机制合并为一条线
• try表达式实际上是首先计算的，并且可以导致函数返回，但它出现在if之后
• 他们返回完全不同的错误，其中一个我们在代码中实际上没有看到，而我们看到了一个
• 这使得try实际上未处理变得不那么明显，因为该块看起来很像一个处理程序块（即使它正在处理一个完全不同的问题）

人们可以从一个稍微不同的角度来处理这种情况，这有利于推动人们处理try s。 如何允许try / else语法包含后续条件（这是许多 I/O 函数的常见模式，它们同时返回err和n ，其中任何一个都可能表明有问题）：

func (f *http2Framer) endWrite() error {
        // ...
        try n := f.w.Write(f.wbuf) else err {
                return errors.Wrap(err, "error writing:")
        } else if n != len(f.wbuf) {
                return io.ErrShortWrite
        }
        return nil
}

在您不处理.Write返回的错误的情况下，您仍然有一个明确的注释.Write可能会出错（正如@thepudds 所指出的那样）：

func (f *http2Framer) endWrite() error {
        // ...
        try n := f.w.Write(f.wbuf)
        if n != len(f.wbuf) {
                return io.ErrShortWrite
        }
        return nil
}

我第二个@daved的回应。 在我看来， @crawshaw突出显示的每个示例都因为try而变得不那么清晰并且更容易出错。

我很高兴在try （关键字）已移至行首的最后几篇文章中支持我。 它确实应该与return共享相同的视觉空间。

鉴于这一点有两个选项，并假设选择了一个，因此为未来的潜在功能设置了一些先例：

一种。）

try f := os.Open(filepath) else err {
    return errors.Wrap(err, "can't open")
}

乙）

f := try os.Open(filepath) else err {
    return errors.Wrap(err, "can't open")
}

两者中哪一个为未来的新关键字使用提供了更大的灵活性？ _（我不知道这个问题的答案，因为我还没有掌握编写编译器的黑暗艺术。）_ 一种方法会比另一种更具限制性吗？

@davecheney @daved @crawshaw
在这一点上，我倾向于同意 Daves：在@crawshaw的示例中，有很多try语句嵌入到行中，这些语句还有很多其他内容。 真的很难发现退出点。 此外，在某些示例中， try括号似乎使事情变得非常混乱。

看到一堆像这样转换的 stdlib 代码非常有用，所以我采用了相同的示例，但根据替代提案重写了它们，这更具限制性：

• try作为关键字
• 每行只有一个try
• try必须在行首

希望这将有助于我们进行比较。 就个人而言，我发现这些示例看起来比它们的原始示例要简洁得多，但不会模糊控制流。 try在任何使用它的地方都非常明显。

文本/模板

func gt(arg1, arg2 reflect.Value) (bool, error) {
        // > is the inverse of <=.
        lessOrEqual, err := le(arg1, arg2)
        if err != nil {
                return false, err
        }
        return !lessOrEqual, nil
}

变成：

func gt(arg1, arg2 reflect.Value) (bool, error) {
        // > is the inverse of <=.
        try lessOrEqual := le(arg1, arg2)
        return !lessOrEqual, nil
}

文本/模板

func index(item reflect.Value, indices ...reflect.Value) (reflect.Value, error) {
...
        switch v.Kind() {
        case reflect.Map:
                index, err := prepareArg(index, v.Type().Key())
                if err != nil {
                        return reflect.Value{}, err
                }
                if x := v.MapIndex(index); x.IsValid() {
                        v = x
                } else {
                        v = reflect.Zero(v.Type().Elem())
                }
        ...
        }
}

变成

func index(item reflect.Value, indices ...reflect.Value) (reflect.Value, error) {
        ...
        switch v.Kind() {
        case reflect.Map:
                try index := prepareArg(index, v.Type().Key())
                if x := v.MapIndex(index); x.IsValid() {
                        v = x
                } else {
                        v = reflect.Zero(v.Type().Elem())
                }
        ...
        }
}

正则表达式/语法：

regexp/syntax/parse.go

func Parse(s string, flags Flags) (*Regexp, error) {
        ...
        if c, t, err = nextRune(t); err != nil {
                return nil, err
        }
        p.literal(c)
        ...
}

变成

func Parse(s string, flags Flags) (*Regexp, error) {
        ...
        try c, t = nextRune(t)
        p.literal(c)
        ...
}

网络/http

网络/http/request.go:readRequest

        mimeHeader, err := tp.ReadMIMEHeader()
        if err != nil {
                return nil, err
        }
        req.Header = Header(mimeHeader)

变成：

        try mimeHeader := tp.ReadMIMEHeader()
        req.Header = Header(mimeHeader)

数据库/sql

        if driverCtx, ok := driveri.(driver.DriverContext); ok {
                connector, err := driverCtx.OpenConnector(dataSourceName)
                if err != nil {
                        return nil, err
                }
                return OpenDB(connector), nil
        }

变成

        if driverCtx, ok := driveri.(driver.DriverContext); ok {
                try connector := driverCtx.OpenConnector(dataSourceName)
                return OpenDB(connector), nil
        }

数据库/sql

        si, err := ctxDriverPrepare(ctx, dc.ci, query)
        if err != nil {
                return nil, err
        }
        ds := &driverStmt{Locker: dc, si: si}

变成

        try si := ctxDriverPrepare(ctx, dc.ci, query)
        ds := &driverStmt{Locker: dc, si: si}

网络/http

        if http2isconnectioncloserequest(req) && dialonmiss {
                // it gets its own connection.
                http2tracegetconn(req, addr)
                const singleuse = true
                cc, err := p.t.dialclientconn(addr, singleuse)
                if err != nil {
                        return nil, err
                }
                return cc, nil
        }

变成

        if http2isconnectioncloserequest(req) && dialonmiss {
                // it gets its own connection.
                http2tracegetconn(req, addr)
                const singleuse = true
                try cc := p.t.dialclientconn(addr, singleuse)
                return cc, nil
        }

网络/http
这个实际上并没有为我们节省任何行，但我发现它更清晰，因为if err == nil是一种相对不常见的结构。

func (f *http2Framer) endWrite() error {
        ...
        n, err := f.w.Write(f.wbuf)
        if err == nil && n != len(f.wbuf) {
                err = io.ErrShortWrite
        }
        return err
}

变成

func (f *http2Framer) endWrite() error {
        ...
        try n := f.w.Write(f.wbuf)
        if n != len(f.wbuf) {
                return io.ErrShortWrite
        }
        return nil
}

网络/http

        if f, err := fr.ReadFrame(); err != nil {
                return nil, err
        } else {
                hc = f.(*http2ContinuationFrame) // guaranteed by checkFrameOrder
        }

变成

        try f := fr.ReadFrame()
        hc = f.(*http2ContinuationFrame) // guaranteed by checkFrameOrder
}

网：

        if ctrlFn != nil {
                c, err := newRawConn(fd)
                if err != nil {
                        return err
                }
                if err := ctrlFn(fd.ctrlNetwork(), laddr.String(), c); err != nil {
                        return err
                }
        }

变成

        if ctrlFn != nil {
                try c := newRawConn(fd)
                try ctrlFn(fd.ctrlNetwork(), laddr.String(), c)
        }

@james-lawrence 回复https://github.com/golang/go/issues/32437#issuecomment -500116099 ：我不记得像可选的, err这样的想法正在认真考虑，不。 我个人认为这是一个坏主意，因为这意味着如果函数更改为添加尾随error参数，现有代码将继续编译，但行为会非常不同。

使用 defer 处理错误很有意义，但它导致需要命名错误和一种新的if err != nil样板。

外部处理程序需要这样做：

func handler(err *error) {
  if *err != nil {
    *err = handle(*err)
  }
} 

像这样使用

defer handler(&err)

外部处理程序只需要编写一次，但许多错误处理函数需要有两个版本：一个是要延迟的，一个是要以常规方式使用的。

内部处理程序需要这样做：

defer func() {
  if err != nil {
    err = handle(err)
  }
}()

在这两种情况下，必须命名外部函数的错误才能访问。

正如我前面在线程中提到的，这可以抽象为一个函数：

func catch(err *error, handle func(error) error) {
  if *err != nil && handle != nil {
    *err = handle(*err)
  }
}

这与@griesemer对nil处理函数的模糊性的担忧相冲突，并且除了必须命名err之外，它还有自己的defer和func(err error) error样板err在外部函数中。

如果try最终成为关键字，那么有一个catch关键字也是有意义的，如下所述。

从语法上讲，它很像handle ：

catch err {
  return handleThe(err)
}

从语义上讲，这将是上面内部处理程序代码的糖：

defer func() {
  if err != nil {
    err = handleThe(err)
  }
}()

由于它有点神奇，它可以抓取外部函数的错误，即使它没有被命名。 （ err之后的 $#$14$ catch更像是catch块的参数名称）。

catch将具有与try相同的限制，即它必须位于具有最终错误返回的函数中，因为它们都是依赖于此的糖。

这远没有最初的handle提案那么强大，但它可以避免为处理它而命名错误的要求，并且它会删除上面讨论的内部处理程序的新样板，同时让它很容易不需要外部处理程序的单独版本的函数。

复杂的错误处理可能需要不使用catch ，因为它可能需要不使用try 。

由于这些都是糖，因此无需将catch与try一起使用。 只要函数返回非nil错误，就会运行catch处理程序，例如，允许坚持一些快速日志记录：

catch err {
  log.Print(err)
  return err
}

或者只是包装所有返回的错误：

catch err {
  return fmt.Errorf("foo: %w", err)
}

@ianlancetaylor

_" 我认为这是个坏主意，因为这意味着如果一个函数更改为添加一个尾随error参数，现有代码将继续编译，但行为会非常不同。"_

这可能是看待它的正确方法，如果您能够控制上游和下游代码，那么如果您需要更改函数签名以便也返回错误，那么您可以这样做。

但是我想请你考虑一下当有人不控制他们自己的包的上游或下游时会发生什么？ 还要考虑可能添加错误的用例，如果需要添加错误但您不能强制下游代码更改会发生什么？

你能想到一个例子，有人会更改签名以添加返回值吗？ 对我来说，他们通常属于 _“我没有意识到会发生错误”_ 或 _“我感觉很懒，不想努力，因为错误可能不会发生。” _

在这两种情况下，我可能会添加一个错误返回，因为很明显需要处理一个错误。 发生这种情况时，如果我因为不想破坏使用我的包的其他开发人员的兼容性而无法更改签名，该怎么办？ 我的猜测是，绝大多数情况下都会发生错误，并且调用不返回错误的函数的代码的行为会非常不同，_anyway._

实际上，我很少做后者，但经常做前者。 但是我注意到第 3 方包经常忽略在它们应该出现的地方捕获错误，我知道这一点是因为当我在 GoLand 中以亮橙色标记每个实例的代码时。 我希望能够提交拉取请求以向我经常使用的包添加错误处理，但如果我这样做，大多数人不会接受它们，因为我会破坏他们的代码签名。

由于不提供向后兼容的方式来添加要由函数返回的错误，因此分发代码并关心不为用户破坏事物的开发人员将无法改进他们的包以包含应有的错误处理。

也许与其考虑代码会表现不同的问题，不如将问题视为一个工程挑战，即如何最小化没有主动捕获错误的方法的缺点？ 这将具有更广泛和更长期的价值。

例如，考虑添加一个必须设置的包错误处理程序，然后才能忽略错误？

坦率地说，Go 除了常规返回值之外还返回错误的习惯用法是它更好的创新之一。 但是，当您改进事物时，经常会出现其他弱点，我认为 Go 的错误处理没有足够的创新。

我们 Gophers 已经变得沉迷于返回错误而不是抛出异常，所以我的问题是 _“为什么我们不应该从每个函数中返回错误？”_ 我们并不总是这样做，因为编写没有错误处理的代码是比用它编码更方便。 因此，当我们认为可以摆脱错误处理时，我们会忽略它。 但我们经常猜错。

所以真的，如果有可能弄清楚如何使代码优雅和可读，我认为返回值和错误确实应该分开处理，并且_every_函数应该有能力返回错误，而不管它过去的函数签名。 让现有代码优雅地处理现在产生错误的代码将是一项值得努力的工作。

我没有提出任何建议，因为我无法设想一种可行的语法，但如果我们想对自己诚实，那么这个线程中的所有内容以及与 Go 的错误处理相关的内容通常都不是关于错误处理和程序逻辑是奇怪的伙伴，所以理想情况下错误最好以某种方式带外处理？

try作为关键字当然有助于提高可读性（与函数调用相比）并且看起来不那么复杂。 @brynbellomy @crawshaw感谢您花时间写出示例。

我想我的一般想法是try做的太多了。 它解决了：调用函数，分配变量，检查错误，如果存在则返回错误。 我建议我们改为削减范围并仅解决条件返回：“如果最后一个 arg 不是 nil 则返回”。

这可能不是一个新想法...但是在浏览了错误反馈wiki中的建议后，我没有找到它（并不意味着它不存在）

有条件回报的迷你提案

摘抄：

err, thing := newThing(name)
refuse nil, err

我也在“另类想法”下将其添加到 wiki

什么都不做似乎也是一个非常合理的选择。

@alexhornbake这给了我一个稍微不同的想法，这会更有用

assert(nil, err)
assert(len(a), len(b))
assert(true, condition)
assert(expected, given)

这样，它不仅适用于错误检查，而且适用于许多类型的逻辑错误。

给定的将被包装在错误中并返回。

@alexhornbake

正如try实际上并没有尝试一样， refuse实际上也没有“拒绝”。 这里的共同意图是我们正在设置一个“保护继电器”（ relay是简短的、准确的，并且是return的首字母），当其中一个接线值满足条件时“跳闸” （即非零错误）。 它是一种断路器，我相信，如果它的设计仅限于无趣的案例以简单地减少一些最低悬的样板，它可以增加价值。 任何远程复杂的东西都应该依赖于简单的 Go 代码。

我也赞扬 cranshaw 浏览标准库的工作，但我得出了一个非常不同的结论……我认为这几乎使所有这些代码片段更难阅读并且更容易产生误解。

        req.Header = Header(try(tp.ReadMIMEHeader())

我经常会错过这可能会出错。 快速阅读让我“好的，将标题设置为事物的 ReadMimeHeader 的标题”。

        if driverCtx, ok := driveri.(driver.DriverContext); ok {
                return OpenDB(try(driverCtx.OpenConnector(dataSourceName))), nil
        }

这一个，我的眼睛只是交叉试图解析该 OpenDB 行。 那里的密度太大了...这显示了所有嵌套函数调用的主要问题，因为您必须从内到外阅读，并且必须在头脑中对其进行解析以找出最里面的部分在哪里.

另请注意，这可以从同一行中的两个不同位置返回。..您将要进行调试，并且会说从该行返回了一个错误，每个人要做的第一件事就是尝试弄清楚为什么 OpenDB 会因为这个奇怪的错误而失败，而实际上是 OpenConnector 失败（反之亦然）。

        ds := &driverStmt{
                Locker: dc,
                si: try(ctxDriverPrepare(ctx, dc.ci, query)),
        }   

这是一个代码可能失败的地方，而以前这是不可能的。 没有try ，结构字面量构造就不会失败。 我的眼睛会掠过它，就像“好的，构建一个 driverStmt ......继续......”实际上很容易错过它，这可能会导致你的函数出错。 以前唯一可能的方法是如果 ctxDriverPrepare 惊慌失措……我们都知道，1.) 基本上永远不会发生，2.) 如果发生，则意味着某些事情严重错误。

使用 try 关键字和语句解决了我的很多问题。 我知道这不是向后兼容的，但我不认为使用更糟糕的版本是向后兼容问题的解决方案。

@daved我不确定我是否遵循。 你不喜欢这个名字，还是不喜欢这个想法？

无论如何，我在这里发布了这个作为替代方案......如果有合法的兴趣，我可以打开一个新问题进行讨论，不想污染这个线程（也许为时已晚？）对原始想法的竖起大拇指会给出我们有一种感觉...当然对替代名称持开放态度。 重要的部分是“有条件返回而不尝试处理分配”。

虽然我喜欢@jimmyfrasche的catch 提议，但我想提出一个替代方案：
go handler fmt.HandleErrorf("copy %s %s", src, dst)
相当于：
go defer func(){ if(err != nil){ fmt.HandleErrorf(&err,"copy %s %s", src, dst) } }()
其中 err 是最后命名的返回值，类型为错误。 但是，也可以在未命名返回值时使用处理程序。 也允许更一般的情况：
go handler func(err *error){ *err = fmt.Errorf("foo: %w", *err) }() `
使用命名返回值（catch 无法解决）的主要问题是 err 是多余的。 当推迟对像fmt.HandleErrorf这样的处理程序的调用时，除了指向错误返回值的指针之外没有合理的第一个参数，为什么要让用户选择犯错呢？

与 catch 相比，主要区别在于 handler 使调用预定义的处理程序更容易一些，但代价是在适当的位置定义它们变得更加冗长。 我不确定这是否理想，但我认为它更符合最初的提议。

@yiyus catch ，正如我定义的那样，它不需要在包含catch err

在catch err {中， err是catch块中错误的名称。 它就像一个函数参数名称。

有了它，就不需要像fmt.HandleErrorf这样的东西了，因为你可以使用常规的fmt.Errorf ：

func f() error {
  catch err {
    return fmt.Errorf("foo: %w", err)
  }
  return errors.New("bar")
}

它返回一个打印为foo: bar的错误。

我不喜欢这种方法，因为：

• try()函数调用会中断父函数中的代码执行。
• 没有return关键字，但代码实际上返回。

提出了很多处理处理程序的方法，但我认为它们经常错过两个关键要求：

1. 它必须明显不同并且比if x, err := thingie(); err != nil { handle(err) }更好。 我认为try x := thingie else err { handle(err) }的建议不符合那个标准。 为什么不直接说if ？

2. 它应该与defer的现有功能正交。 也就是说，它应该足够不同，很明显，所提出的处理机制本身是需要的，而不会在句柄和延迟交互时产生奇怪的极端情况。

在我们讨论try /handle 的替代机制时，请牢记这些需求。

@carlmjohnson我喜欢@jimmyfrasche的catch关于您的第 2 点的想法 - 它只是defer的语法糖，它可以节省 2 行并让您避免命名错误返回值（在如果您还没有的话，turn 还需要您命名所有其他人）。 它不会引发defer的正交性问题，因为它是defer 。

呼应@ubombi所说的：

try() 函数调用中断父函数中的代码执行。 没有 return 关键字，但代码实际返回。

在 Ruby 中，procs 和 lambdas 是try所做的一个示例...... proc 是一个代码块，它的 return 语句不是从块本身返回，而是从调用者返回。

这正是try所做的……它只是一个预定义的 Ruby 过程。

我想如果我们要走那条路，也许我们实际上可以通过引入proc functions来让用户定义自己的try函数

我仍然更喜欢if err != nil ，因为它更具可读性，但我认为try如果用户定义自己的过程会更有益：

proc try(err *error, msg string) {
  if *err != nil {
    *err = fmt.Errorf("%v: %w", msg, *err)
    return
  }
}

然后你可以调用它：

func someFunc() (string, error) {
  err := doSomething()
  try(&err, "someFunc failed")
}

这样做的好处是您可以用自己的方式定义错误处理。 您还可以将proc设为公开的、私有的或内部的。

它也比原始 Go2 提案中的handle {}子句更好，因为您只能为整个代码库定义一次，而不是在每个函数中定义它。

可读性的一个考虑因素是 func() 和 proc() 的调用方式可能不同，例如func()和proc!()以便程序员知道 proc 调用实际上可能从调用函数。

@marwan-at-work，在您的示例中try(err, "someFunc failed")不应该是try(&err, "someFunc failed")吗？

@dpinela感谢您的更正，更新了代码:)

我们在这里试图覆盖的常见做法是在许多语言中展开的标准堆栈在异常中所暗示的内容，（因此选择了“尝试”这个词......）。
但是，如果我们只能允许一个函数（...try() 或其他）在跟踪中跳回两级，那么

try := handler(err error) {     //which corelates with - try := func(err error) 
   if err !=nil{
       //do what ever you want to do when there's an error... log/print etc
       return2   //2 levels
   }
} 

然后像这样的代码
f := try(os.Open(文件名))
可以完全按照提案的建议做，但是作为一个函数（或实际上是一个“处理函数”），开发人员将更多地控制函数的作用，在不同情况下如何格式化错误，使用类似的处理程序处理（比如说）os.Open 的代码，而不是每次都写 fmt.Errorf("error opening file %s ....")。
这也会强制错误处理，就好像没有定义“try”一样——它是一个编译时错误。

@guybrand拥有这样的两级回报return2 （或 Smalltalk 中称为一般概念的“非本地回报”）将是一个很好的通用机制（ @mikeschinkel在#32473 中也建议） . 但是您的建议似乎仍然需要try ，所以我看不出return2的原因 - try可以只做return . 如果也可以在本地编写try会更有趣，但这对于任意签名是不可能的。

@griesemer

_“所以我看不出return2的原因 - try可以做return 。”_

一个原因 - 正如我在 #32473 _（感谢您的参考）_ 中指出的那样 - 除了return之外，还允许break和continue的多个级别。

再次感谢大家的所有新评论； 跟上讨论并撰写大量反馈是一项重要的时间投资。 甚至更好的是，尽管有时争论不休，但到目前为止，这一直是一个相当平民的话题。 谢谢！

这是另一个快速摘要，这次更简洁； 向那些我没有提及、忘记或误解的人道歉。 在这一点上，我认为一些更大的主题正在出现：

1）一般来说，使用try功能的内置函数被认为是一个糟糕的选择：鉴于它会影响控制流，它应该_至少_一个关键字（ @carloslenz “更喜欢使它成为一个没有插入语”）; try作为表达式似乎不是一个好主意，它会损害可读性（ @ChrisHines ，@jimmyfrasche），它们是“没有return的返回”。 @brynbellomy对用作标识符的try进行了实际分析； 似乎很少有百分比，因此可能会在不影响太多代码的情况下使用关键字路线。

2） @crawshaw花了一些时间分析了标准库中的几百个用例，并得出结论，所提议的try几乎总是能提高可读性。 @jimmyfrasche得出了相反的结论。

3) 另一个主题是使用defer进行错误修饰并不理想。 @josharian指出defer总是在函数返回时运行，但如果它们在这里是为了错误修饰，我们只关心它们的主体是否有错误，这可能是混乱的根源。

4) 许多人写了改进提案的建议。 @zeebo和 @patrick-nyt 支持gofmt在一行上格式化简单的if语句（并对现状感到满意）。 @jargv建议try() （不带参数）可以返回指向当前“待处理”错误的指针，这将消除命名错误结果的需要，以便人们可以在defer中访问它@masterada建议改用errorfunc() 。 @velovix恢复了 2 参数try的想法，其中第二个参数是错误处理程序。

@klaidliadon ， @networkimprov支持特殊的“赋值运算符”，例如f, # := os.Open()而不是try 。 @networkimprov提交了一份更全面的替代提案来调查此类方法（请参阅问题 #32500）。 @mikeschinkel还提交了一个替代提案，建议引入两个新的通用语言功能，这些功能也可用于错误处理，而不是特定于错误的try （参见问题 #32473）。 @josharian恢复了我们去年在 GopherCon 讨论的一种可能性，其中try不会在错误时返回，而是跳转（使用goto ）到名为error的标签（或者, try可能采用目标标签的名称）。

5）关于try作为关键词的话题，出现了两行思路。 @brynbellomy建议了一个可以替代地指定处理程序的版本：

a, b := try f()
a, b := try f() else err { /* handle error */ }

@thepudds更进一步，在行首建议try ，使try与return具有相同的可见性：

try a, b := f()

这两者都可以与defer一起使用。

@griesemer

感谢@mikeschinkel #32473 的参考，它确实有很多共同点。

关于

但是您的建议似乎仍然需要尝试
虽然我的建议可以用“任何”处理程序而不是保留的“内置/关键字/表达式”来实现，但我不认为“try()”是一个坏主意（因此没有否决它），我正在尝试“扩大范围”——因此它会显示出更多的优势，许多人预计“一旦推出 2.0”

我认为这也可能是您在上次总结中报告的“混合情绪”的来源——它不是“try() 不能改进错误处理”——确实如此，它是“等待 Go 3.0 解决其他一些重大错误处理痛苦”上面所说的人，看起来太长了:)

我正在进行一项关于“错误处理痛苦”的调查（并且听起来有些痛苦仅仅是“我不使用好的做法”，而有些痛苦我什至没有想到人们（主要来自其他语言）想做 - 从很酷到WTF）。

希望我能尽快分享一些有趣的结果。

最后-感谢您的出色工作和耐心！

简单地看一下当前提议的语法的长度与现在可用的语法相比，只需要返回错误而不处理它或修饰它的情况是获得最大便利的情况。 到目前为止我最喜欢的语法示例：

try a, b := f() else err { return fmt.Errorf("Decorated: %s", err); }
if a,b, err :=f;  err != nil { return fmt.Errorf("Decorated: %s", err); }
try a, b := f()
if a,b, err :=f;  err != nil { return err; }

所以，与我之前的想法不同，也许改变 go fmt 就足够了，至少对于装饰/处理的错误情况。 虽然只是传递错误案例，但对于这个非常常见的用例，像 try 这样的东西可能仍然是可取的语法糖。

关于try else ，我认为在初始注释中像fmt.HandleErrorf （编辑：我假设它在输入为 nil 时返回 nil ）这样的条件错误函数可以正常工作，因此添加else是不必要的。

a, b, err := doSomething()
try fmt.HandleErrorf(&err, "Decorated "...)

像这里的许多其他人一样，我更喜欢try作为语句而不是表达式，主要是因为改变控制流的表达式与 Go 完全不同。 也因为这不是一个表达式，它应该在行首。

我也同意@daved这个名字不合适。 毕竟，我们在这里试图实现的是一个受保护的赋值，那么为什么不像在 Swift 中那样使用guard并让else子句成为可选的呢？ 就像是

GuardStmt = "guard" ( Assignment | ShortVarDecl | Expression ) [  "else" Identifier Block ] .

其中Identifier是绑定在以下Block中的错误变量名称。 如果没有else子句，只需从当前函数返回（并在需要时使用延迟处理程序来修饰错误）。

我最初不喜欢else子句，因为它只是围绕通常赋值的语法糖，然后是if err != nil ，但是在看到一些示例之后，它才有意义：使用guard使意图更清晰。

编辑：有些人建议使用诸如catch之类的东西来以某种方式指定不同的错误处理程序。 我发现else在语义上同样可行，而且它已经在语言中了。

虽然我喜欢 try-else 语句，但这个语法怎么样？

a, b, (err) := func() else { return err }

表达式try - else是一个三元运算符。

a, b := try f() else err { ... }
fmt.Println(try g() else err { ... })`

语句try - else是一个if语句。

try a, b := f() else err { ... }
// (modulo scope of err) same as
a, b, err := f()
if err != nil { ... }

带有可选处理程序的内置try可以使用辅助函数（如下）或不使用try （未图示，我们都知道它的样子）来实现。

a, b := try(f(), decorate)
// same as
a, b := try(g())
// where g is
func g() (whatever, error) {
  x, err := f()
  if err != nil {
    try(decorate(err))
  }
  return x, nil
}

所有这三个都减少了样板文件并帮助包含错误范围。

它为内置try提供了最大的节省，但这存在设计文档中提到的问题。

对于语句try - else ，它提供了优于使用if而不是try的优势。 但是优势是如此微不足道，以至于我很难看到它证明自己是合理的，尽管我确实喜欢它。

三者都假设需要对个别错误进行特殊错误处理是很常见的。

可以在defer中平等地处理所有错误。 如果在每个else块中进行相同的错误处理，那有点重复：

func printSum(a, b string) error {
  try x := strconv.Atoi(a) else err {
    return fmt.Errorf("printSum: %w", err)
  }
  try y := strconv.Atoi(b) else err {
    return fmt.Errorf("printSum: %w", err)
  }
  fmt.Println("result:", x + y)
  return nil
}

我当然知道有时某个错误需要特殊处理。 这些是我记忆中突出的例子。 但是，如果这种情况只发生在 100 次中的 1 次，那么保持try简单并且在这些情况下不使用try不是更好吗？ 另一方面，如果它更像是 10 次中的 1 次，则添加else /handler 似乎更合理。

有趣的是，看看没有else /handler 的try与有else /handler 的 $#$23$# try的实际分布频率会很有用，不过这不是容易收集的数据。

我想扩展@jimmyfrasche最近的评论。

该提案的目标是减少样板

    a, b, err := f()
    if err != nil {
        return nil, err
    }

这段代码很容易阅读。 只有当我们可以显着减少样板时，才值得扩展语言。 当我看到类似的东西

    try a, b := f() else err { return nil, err }

我不禁觉得我们并没有节省那么多。 我们节省了三行，这很好，但据我计算，我们正在将 56 个字符减少到 46 个字符。 那不是很多。 相比于

    a, b := try(f())

从 56 个字符减少到 18 个字符，显着减少。 虽然try语句使控制流的潜在变化更加清晰，但总体而言，我认为该语句没有更具可读性。 虽然从好的方面来说， try语句更容易注释错误。

无论如何，我的观点是：如果我们要改变某些东西，它应该显着减少样板文件或者应该显着提高可读性。 后者相当困难，所以任何改变都需要对前者真正起作用。 如果我们只对样板进行少量减少，那么在我看来这是不值得做的。

和其他人一样，我要感谢@crawshaw提供的示例。

在阅读这些示例时，我鼓励人们尝试采用一种思维方式，在这种思维方式中，由于try函数，您不必担心控制流。 我相信，也许是错误的，这种控制流将很快成为懂语言的人的第二天性。 在正常情况下，我相信人们将不再担心错误情况下会发生什么。 尝试阅读这些示例，同时对try上釉，就像您已经对if err != nil { return err }上釉一样。

在阅读完这里的所有内容并进一步思考之后，我不确定我是否认为 try 甚至是值得添加的声明。

1. 它的基本原理似乎是减少错误处理样板代码。 恕我直言，它“整理”了代码，但并没有真正消除复杂性； 它只是掩盖了它。 这似乎没有足够的理由。 “去” 语法精美地捕获了启动并发线程。我在这里没有那种“啊哈！”的感觉。感觉不对。成本/收益比不够大。

2. 它的名字并不反映它的功能。 以最简单的形式，它的作用是：“如果函数返回错误，则从调用者返回错误”，但这太长了 :-) 至少需要一个不同的名称。

3. 使用 try 的隐式错误返回，感觉就像 Go 有点不情愿地支持异常处理。 也就是说，如果 A 在 try 守卫中调用 be，B 在 try 守卫中调用 C，C 在 try 守卫中调用 D，如果 D 返回错误，则实际上您已导致非本地 goto。 感觉太“神奇”了。

4. 但我相信可能会有更好的方法。 现在选择尝试将关闭该选项。

@ianlancetaylor
如果我正确理解“尝试其他”建议，似乎else块是可选的，并保留给用户提供的处理。 在您的示例try a, b := f() else err { return nil, err }中else子句实际上是多余的，整个表达式可以简单地写成try a, b := f()

我同意@ianlancetaylor ，
可读性和样板是两个主要问题，也许是驱动力
go 2.0 错误处理（尽管我可以添加一些其他重要的问题）

此外，当前

a, b, err := f()
if err != nil {
    return nil, err
}

具有高度可读性。
既然我相信

if a, b, err := f(); err != nil {
    return nil, err
}

几乎一样可读，但它的范围“问题”，也许是

ifErr a, b, err := f() {
    return nil, err
}

那只会 ; err != nil 部分，并且不会创建范围，或者

相似地

尝试 a, b, err := f() {
返回零，错误
}

保留额外的两行，但仍然可读。

2019 年 6 月 11 日星期二 20:19 Dmitriy Matrenichev， notifications @github.com
写道：

@ianlancetaylor https://github.com/ianlancetaylor
如果我正确理解“尝试其他”的建议，似乎其他阻止
是可选的，并为用户提供的处理保留。 在你的例子中
try a, b := f() else err { return nil, err } else 子句实际上是
多余的，整个表达式可以简单地写成 try a, b :=
F（）

—
你收到这个是因为你被提到了。
直接回复此邮件，在 GitHub 上查看
https://github.com/golang/go/issues/32437?email_source=notifications&email_token=ABNEY4XPURMASWKZKOBPBVDPZ7NALA5CNFSM4HTGCZ72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXN3VDA#issuecomment-500939404 ，
或使线程静音
https://github.com/notifications/unsubscribe-auth/ABNEY4SAFK4M5NLABF3NZO3PZ7NALANCNFSM4HTGCZ7Q
.

@ianlancetaylor

无论如何，我的观点是：如果我们要改变某些东西，它应该显着减少样板文件或者应该显着提高可读性。 后者相当困难，所以任何改变都需要对前者真正起作用。 如果我们只对样板进行少量减少，那么在我看来这是不值得做的。

同意，并且考虑到else只是语法糖（语法很奇怪！），很可能很少使用，我不太关心它。 不过，我仍然希望try成为一个声明。

@ianlancetaylor与@DmitriyMV相呼应， else块将是可选的。 让我举一个例子来说明两者（就实际代码中已处理与未处理的try块的相对比例而言，这似乎并不太离谱）：

func createMergeCommit(r *repo.Repo, index *git.Index, remote *git.Remote, remoteBranch *git.Branch) error {
    headRef, err := r.Head()
    if err != nil {
        return err
    }

    parentObjOne, err := headRef.Peel(git.ObjectCommit)
    if err != nil {
        return err
    }

    parentObjTwo, err := remoteBranch.Reference.Peel(git.ObjectCommit)
    if err != nil {
        return err
    }

    parentCommitOne, err := parentObjOne.AsCommit()
    if err != nil {
        return err
    }

    parentCommitTwo, err := parentObjTwo.AsCommit()
    if err != nil {
        return err
    }

    treeOid, err := index.WriteTree()
    if err != nil {
        return err
    }

    tree, err := r.LookupTree(treeOid)
    if err != nil {
        return err
    }

    remoteBranchName, err := remoteBranch.Name()
    if err != nil {
        return err
    }

    userName, userEmail, err := r.UserIdentityFromConfig()
    if err != nil {
        userName = ""
        userEmail = ""
    }

    var (
        now       = time.Now()
        author    = &git.Signature{Name: userName, Email: userEmail, When: now}
        committer = &git.Signature{Name: userName, Email: userEmail, When: now}
        message   = fmt.Sprintf(`Merge branch '%v' of %v`, remoteBranchName, remote.Url())
        parents   = []*git.Commit{
            parentCommitOne,
            parentCommitTwo,
        }
    )

    _, err = r.CreateCommit(headRef.Name(), author, committer, message, tree, parents...)
    if err != nil {
        return err
    }
    return nil
}

func createMergeCommit(r *repo.Repo, index *git.Index, remote *git.Remote, remoteBranch *git.Branch) error {
    try headRef := r.Head()
    try parentObjOne := headRef.Peel(git.ObjectCommit)
    try parentObjTwo := remoteBranch.Reference.Peel(git.ObjectCommit)
    try parentCommitOne := parentObjOne.AsCommit()
    try parentCommitTwo := parentObjTwo.AsCommit()
    try treeOid := index.WriteTree()
    try tree := r.LookupTree(treeOid)
    try remoteBranchName := remoteBranch.Name()
    try userName, userEmail := r.UserIdentityFromConfig() else err {
        userName = ""
        userEmail = ""
    }

    var (
        now       = time.Now()
        author    = &git.Signature{Name: userName, Email: userEmail, When: now}
        committer = &git.Signature{Name: userName, Email: userEmail, When: now}
        message   = fmt.Sprintf(`Merge branch '%v' of %v`, remoteBranchName, remote.Url())
        parents   = []*git.Commit{
            parentCommitOne,
            parentCommitTwo,
        }
    )

    try r.CreateCommit(headRef.Name(), author, committer, message, tree, parents...)
    return nil
}

虽然try / else模式并没有比复合if节省很多字符，但它确实：

• 将错误处理语法与未处理的try统一起来
• 一目了然地表明条件块正在处理错误条件
• 让我们有机会减少复合if遭受的范围界定怪异

不过，未处理的try可能是最常见的。

@ianlancetaylor

尝试阅读这些示例，同时进行尝试，就像您已经对 if err != nil { return err } 进行检查一样。

我不认为这是可能的/平等的。 缺少尝试存在于拥挤的行中，或者它确切地包装了什么，或者一行中有多个实例......这些与轻松/快速标记返回点而不担心其中的细节不同。

@ianlancetaylor

当我看到一个停车标志时，我通过形状和颜色来识别它，而不是通过阅读印在上面的文字并思考其更深层次的含义。

我的眼睛可能会在if err != nil { return err }上呆滞，但同时它仍然会记录下来——清晰而迅速。

我喜欢try -statement 变体的原因是它减少了样板，但以一种既容易上釉又难以错过的方式。

这可能意味着在这里或那里多出一行，但这仍然比现状少。

@brynbellomy

1. 您如何处理返回多个值的函数，例如：
   func createMergeCommit(r *repo.Repo, index *git.Index, remote *git.Remote, remoteBranch *git.Branch) (hash , error) {
2. 您将如何跟踪返回错误的正确行
3. 放弃范围问题（可以通过其他方式解决），我不确定

func createMergeCommit(r *repo.Repo, index *git.Index, remote *git.Remote, remoteBranch *git.Branch) error {

    if headRef, err := r.Head(); err != nil {
        return err
    } else if parentObjOne, err := headRef.Peel(git.ObjectCommit); err != nil {
        return err
    } else parentObjTwo, err := remoteBranch.Reference.Peel(git.ObjectCommit); err != nil {
        return err
    } ...

在可读性方面并没有那么不同，但是（或 fmt.Errorf("error with getting head : %s", err.Error() ）允许您轻松修改和提供额外数据。

仍然是一个唠叨的是

1. 必须重新检查； 错误！= 无
2. 如果我们不想提供额外信息，则按原样返回错误 - 在某些情况下这不是一个好习惯，因为您依赖于您调用的函数来反映“好”错误，该错误将提示“出了什么问题”，在 file.Open 、 close 、 Remove 、 Db 函数等的情况下，许多函数调用都可以返回相同的错误（我们可以争论这是否意味着编写错误的开发人员做得很好......但它确实发生了） - 然后 - 你有一个错误，可能从调用的函数中记录它
   “ createMergeCommit”，但无法将其跟踪到它发生的确切行。

对不起，如果有人已经发布了这样的东西（有很多好主意：P）这个替代语法怎么样：

fail := func(err error) error {
  log.Print("unexpected error", err)
  return err
}

a, b, err := f1()          // normal
c, d := f2() -> throw      // calls throw(err)
e, f := f3() -> panic      // calls panic(err)
g, h := f4() -> t.Error    // calls t.Error(err)
i, j := f5() -> fail       // calls fail(err)

也就是说，您在函数调用的右侧有一个-> handler ，如果返回的 err != nil 则调用该函数调用。 处理程序是任何接受错误作为单个参数并可选择返回错误的函数（即func(error)或func(error) error ）。 如果处理程序返回 nil 错误，则函数继续，否则返回错误。

所以a := b() -> handler相当于：

a, err := b()
if err != nil {
  if herr := handler(err); herr != nil {
    return herr
  }
}

现在，作为快捷方式，您可以支持try内置（或关键字或?=运算符或其他），它是a := b() -> throw的缩写，因此您可以编写如下内容：

func() error {
  a, b := try(f1())
  c, d := try(f2())
  e, f := try(f3())
  ...
  return nil
}() -> panic // or throw/fail/whatever

就我个人而言，我发现?=运算符比 try 关键字/内置运算符更容易阅读：

func() error {
  a, b ?= f1()
  c, d ?= f2()
  e, f ?= f3()
  ...
  return nil
}() -> panic

注意：这里我使用 throw 作为内置函数的占位符，它将错误返回给调用者。

到目前为止，我还没有对错误处理提案发表评论，因为我普遍赞成，而且我喜欢他们前进的方式。 提案中定义的 try 函数和@thepudds提出的 try 语句似乎都是对语言的合理补充。 我相信 Go 团队想出的任何东西都会是好的。

我想提出我认为提案中定义 try 的方式的一个小问题，以及它可能如何影响未来的扩展。

Try 被定义为一个接受可变数量参数的函数。

func try(t1 T1, t2 T2, … tn Tn, te error) (T1, T2, … Tn)

由于 Go 中多个返回值的工作方式，将函数调用的结果传递给try就像在try(f())中一样隐式地工作。

通过我对提案的阅读，以下片段既有效又在语义上等效。

a, b = try(f())
//
u, v, err := f()
a, b = try(u, v, err)

该提案还提出了使用额外参数扩展try的可能性。

如果我们确定具有某种形式的显式提供的错误处理函数或任何其他附加参数是一个好主意，那么很可能将该附加参数传递给 try 调用。

假设我们要添加一个处理程序参数。 它可以位于参数列表的开头或结尾。

var h handler
a, b = try(h, f())
// or
a, b = try(f(), h)

把它放在开头是行不通的，因为（鉴于上面的语义） try将无法区分显式处理程序参数和返回处理程序的函数。

func f() (handler, error) { ... }
func g() (error) { ... }
try(f())
try(h, g())

把它放在最后可能会起作用，但是 try 在语言中是唯一的，因为它是唯一在参数列表开头带有可变参数的函数。

这两个问题都不是什么大问题，但它们确实让try感觉与语言的其余部分不一致，所以我不确定try将来是否容易扩展，因为提案状态。

@神奇

拥有一个处理程序很强大，也许：
我你已经声明了 h，

你可以

var h handler
a, b, h = f()

要么

a, b, h.err = f()

如果它是类似函数的：

h:= handler(err error){
 log(...)
 return ....
} 

然后有人建议

a, b, h(err) = f()

所有人都可以调用处理程序
您还可以按照一些建议“选择”返回或仅捕获错误（conitnue/break/return）的处理程序。

因此可变参数问题消失了。

@brynbellomy 的else建议的一种替代方法：

a, b := try f() else err { /* handle error */ }

可能是在 else 之后立即支持装饰功能：

decorate := func(err error) error { return fmt.Errorf("foo failed: %v", err) }

try a, b := f() else decorate
try c, d := g() else decorate

也许还有一些实用功能类似于：

decorate := fmt.DecorateErrorf("foo failed")

装饰函数可以具有签名func(error) error ，并在出现错误时由 try 调用，就在 try 从被尝试的关联函数返回之前。

这在精神上类似于提案文件中较早的“设计迭代”之一：

f := try(os.Open(filename), handler)              // handler will be called in error case

如果有人想要更复杂的东西或语句块，他们可以改用if （就像他们今天一样）。

也就是说，@brynbellomy 在https://github.com/golang/go/issues/32437#issuecomment -500949780 中的示例中显示的try的视觉对齐有一些好处。

如果选择该方法用于统一错误修饰，所有这些仍然可以与defer一起使用（或者甚至在理论上可能存在注册修饰函数的替代形式，但这是一个单独的点）。

无论如何，我不确定这里最好的是什么，但想明确另一个选项。

这是@brynbellomy用try函数重写的示例，使用var块来保留@thepudds在https://github.com/golang/go/issues中指出的良好对齐

package main

import (
    "fmt"
    "time"
)

func createMergeCommit(r *repo.Repo, index *git.Index, remote *git.Remote, remoteBranch *git.Branch) error {
    var (
        headRef          = try(r.Head())
        parentObjOne     = try(headRef.Peel(git.ObjectCommit))
        parentObjTwo     = try(remoteBranch.Reference.Peel(git.ObjectCommit))
        parentCommitOne  = try(parentObjOne.AsCommit())
        parentCommitTwo  = try(parentObjTwo.AsCommit())
        treeOid          = try(index.WriteTree())
        tree             = try(r.LookupTree(treeOid))
        remoteBranchName = try(remoteBranch.Name())
    )

    userName, userEmail, err := r.UserIdentityFromConfig()
    if err != nil {
        userName = ""
        userEmail = ""
    }

    var (
        now       = time.Now()
        author    = &git.Signature{Name: userName, Email: userEmail, When: now}
        committer = &git.Signature{Name: userName, Email: userEmail, When: now}
        message   = fmt.Sprintf(`Merge branch '%v' of %v`, remoteBranchName, remote.Url())
        parents   = []*git.Commit{
            parentCommitOne,
            parentCommitTwo,
        }
    )

    _, err = r.CreateCommit(headRef.Name(), author, committer, message, tree, parents...)
    return err
}

它与try -statement 版本一样简洁，我认为它同样具有可读性。 由于try是一个表达式，因此可以消除其中一些中间变量，但会牺牲一些可读性，但这似乎更像是一种风格问题。

不过，它确实提出了try如何在var块中工作的问题。 我假设var的每一行都算作一个单独的语句，而不是整个块都是一个语句，就何时分配的顺序而言。

如果“尝试”提案明确指出使用简单语句计数来近似测试覆盖率统计的工具（例如 cmd/cover）的后果，那将是很好的。 我担心不可见的错误控制流可能会导致计数不足。

@thepudds

尝试 a, b := f() 否则装饰

也许是我的脑细胞烧得太深了，但这对我的打击太大了

try a, b := f() ;catch(decorate)

和一个滑坡到

a, b := f()
catch(decorate)

我想你可以看到它的领先地位，对我来说比较

    try headRef := r.Head()
    try parentObjOne := headRef.Peel(git.ObjectCommit)
    try parentObjTwo := remoteBranch.Reference.Peel(git.ObjectCommit)
    try parentCommitOne := parentObjOne.AsCommit()
    try parentCommitTwo := parentObjTwo.AsCommit()
    try treeOid := index.WriteTree()
    try tree := r.LookupTree(treeOid)
    try remoteBranchName := remoteBranch.Name()

和

    try ( 
    headRef := r.Head()
    parentObjOne := headRef.Peel(git.ObjectCommit)
    parentObjTwo := remoteBranch.Reference.Peel(git.ObjectCommit)
    parentCommitOne := parentObjOne.AsCommit()
    parentCommitTwo := parentObjTwo.AsCommit()
    treeOid := index.WriteTree()
    tree := r.LookupTree(treeOid)
    remoteBranchName := remoteBranch.Name()
    )

（甚至是最后的捕获）
第二个更具可读性，但强调了下面的函数返回 2 个 vars 的事实，我们神奇地丢弃了一个，将它收集到 "magic returned err" 中。

    try(err) ( 
    headRef := r.Head()
    parentObjOne := headRef.Peel(git.ObjectCommit)
    parentObjTwo := remoteBranch.Reference.Peel(git.ObjectCommit)
    parentCommitOne := parentObjOne.AsCommit()
    parentCommitTwo := parentObjTwo.AsCommit()
    treeOid := index.WriteTree()
    tree := r.LookupTree(treeOid)
    remoteBranchName := remoteBranch.Name()
    ); err!=nil {
      //handle the err
    }

至少明确设置要返回的变量，并让我在函数中随时处理它。

只是插入一个特定的评论，因为我没有看到其他人明确提到它，特别是关于更改gofmt以支持以下单行格式或任何变体：

if f() { return nil, err }

请不。 如果我们想要单行if那么请制作单行if ，例如：

if f() then return nil, err

但是请，请，请不要接受删除换行符的语法沙拉，因为这些换行符会使使用大括号的代码更容易阅读。

我想强调几件在激烈的讨论中可能被遗忘的事情：

1) 这个提议的重点是让常见的错误处理淡入后台——错误处理不应该支配代码。 但仍应明确。 任何使错误处理更加突出的替代建议都没有抓住重点。 正如@ianlancetaylor已经说过的，如果这些替代建议不能显着减少样板文件的数量，我们可以继续使用if语句。 （减少样板的请求​​来自 Go 社区。）

2）对当前提案的抱怨之一是需要命名错误结果才能访问它。 除非替代方案引入了额外的语法，即更多样板文件（例如... else err { ... }等）来显式命名该变量，否则任何替代方案都会有同样的问题。 但有趣的是：如果我们不关心修饰错误并且不命名结果参数，但仍然需要显式return因为有一个显式处理程序，那么return语句将不得不枚举所有（通常为零）结果值，因为在这种情况下不允许裸返回。 特别是如果一个函数在没有修饰错误的情况下执行大量错误返回，则那些显式返回（ return nil, err等）会添加到样板文件中。 当前的提案以及任何不需要明确的return的替代方案都取消了这一点。 另一方面，如果确实想要修饰错误，当前提案_要求_一个人命名错误结果（以及所有其他结果）以访问错误值。 这有一个很好的副作用，即在显式处理程序中可以使用裸返回，而不必重复所有其他结果值。 （我知道对裸返回有一些强烈的感觉，但现实是，当我们只关心错误结果时，必须枚举所有其他（通常为零）结果值是一件真正令人讨厌的事情 - 它没有增加任何对代码的理解）。 换句话说，必须命名错误结果以便对其进行修饰可以进一步减少样板。

@magical感谢您指出这一点。 我在发布提案后不久就注意到了同样的情况（但没有提出来以免进一步引起混淆）。 您是正确的， try无法扩展。 幸运的是，修复很容易。 （碰巧我们早期的内部提案没有这个问题 - 当我重写我们的最终版本以进行发布并尝试简化try以更紧密地匹配现有的参数传递规则时，它被引入了。这看起来不错- 但事实证明，有缺陷，而且大多无用 - 能够编写try(a, b, c, handle)的好处。）

try的早期版本大致定义如下： try(expr, handler)将一个（或可能两个）表达式作为参数，其中第一个表达式可能是多值的（仅当表达式为函数调用）。 该（可能是多值）表达式的最后一个值必须是error类型，并且该值针对 nil 进行测试。 （等等 - 你可以想象的其余部分）。

无论如何，关键是try语法上只接受一个，或者可能是两个表达式。 （但是描述try的语义有点困难。）结果将是这样的代码：

a, b := try(u, v, err)

将不再被允许。 但是首先没有理由让这项工作：在大多数情况下（除非a和b被命名为结果）这个代码 - 如果出于某种原因很重要 - 可以很容易地重写为

a, b := u, v  // we don't care if the assignment happens in case of an error
try(err)

（或根据需要使用if语句）。 但是，这似乎并不重要。

该 return 语句将必须枚举所有（通常为零）结果值，因为在这种情况下不允许裸返回

不允许赤裸裸的退货，但可以尝试。 我喜欢 try（作为函数或语句）的一件事是，当返回错误时，我不再需要考虑如何设置非错误值，我只会使用 try。

@griesemer感谢您的解释。 这也是我得出的结论。

对try作为声明的简短评论：我认为可以在https://github.com/golang/go/issues/32437#issuecomment -501035322 中的示例中看到， try埋葬了lede。 代码变成了一系列try语句，它掩盖了代码实际在做什么。

现有代码可能会在if err != nil块之后重用新声明的错误变量。 隐藏变量会破坏这一点，并且将命名的返回变量添加到函数签名中并不总是可以修复它。

也许最好保留错误声明/赋值，并找到一个单行错误处理 stmt。

err := f() // followed by one of

on err, return err            // any type can be tested for non-zero
on err, return fmt.Errorf(...)
on err, fmt.Println(err)      // doesn't stop the function
on err, hname err             // handler invocation without parens
on err, ignore err            // optional ignore handler logs error if defined

if err, return err            // alternatively, use if

handle hname(err error, clr caller) { // type caller has results of runtime.Caller()
   if err == io.Bad { return err }
   fmt.Println(clr.name, err)
}

try子表达式可能会出现恐慌，这意味着永远不会出现错误。 它的一个变体可以忽略任何错误。

f(try g()) // panic on error
f(try_ g()) // ignore any error

这个提议的重点是让常见的错误处理淡入后台——错误处理不应该支配代码。 但仍应明确。

我喜欢将try列为声明的评论的想法。 它很明确，仍然很容易掩盖（因为它是固定长度的），但不容易掩盖（因为它总是在同一个地方）它们可以隐藏在拥挤的线上。 如前所述，它也可以与defer fmt.HandleErrorf(...)结合使用，但它确实存在滥用命名参数以包装错误的陷阱（这对我来说仍然是一个聪明的 hack。聪明的 hack 是不好的。）

我不喜欢将try作为表达式的原因之一是它要么太容易掩盖，要么不容易掩盖。 举以下两个例子：

尝试作为表达

// Too hidden, it's in a crowded function with many symbols that complicate the function.

f, err := os.OpenFile(try(FileName()), os.O_APPEND|os.O_WRONLY, 0600)

// Not easy enough, the word "try" already increases horizontal complexity, and it
// being an expression only encourages more horizontal complexity.
// If this code weren't collapsed to multiple lines, it would be extremely
// hard to read and unclear as to what's executing when.

fullContents := try(io.CopyN(
    os.Stdout,
    try(net.Dial("tcp", "localhost:"+try(buf.ReadString("\n"))),
    try(strconv.Atoi(try(buf.ReadString("\n")))),
))

尝试作为陈述

// easy to see while still not being too verbose

try name := FileName()
os.OpenFile(name, os.O_APPEND|os.O_WRONLY, 0600)

// does not allow for clever one-liners, code remains much more readable.
// also, the code reads in sequence from top-to-bottom.

try port := r.ReadString("\n")
try lengthStr := r.ReadString("\n")
try length := strconv.Atoi(lengthStr)

try con := net.Dial("tcp", "localhost:"+port)
try io.CopyN(os.Stdout, con, length)

外卖

我承认，这段代码绝对是人为的。 但我要说的是，一般来说， try作为表达式在以下情况下效果不佳：

1. 不需要太多错误检查的拥挤表达式的中间
2. 需要大量错误检查的相对简单的多行语句

但是，我同意@ianlancetaylor的观点，即以try开头的每一行似乎确实妨碍了每个语句的重要部分（正在定义的变量或正在执行的函数）。 但是我认为因为它位于同一位置并且是固定宽度，所以更容易掩盖，同时仍然注意到它。 不过，每个人的眼光都不一样。

我还认为，在代码中鼓励聪明的单行代码通常只是一个坏主意。 我很惊讶我能像我的第一个例子那样制作出如此强大的单行代码，它是一个值得拥有自己的全部功能的片段，因为它做了很多事情——但如果我没有折叠它，它就可以放在一行上为便于阅读，改为多个。 一站式服务：

fullContents := try(io.CopyN(os.Stdout, try(net.Dial("tcp", "localhost:"+try(r.ReadString("\n"))), try(strconv.Atoi(try(r.ReadString("\n"))))))

它从*bufio.Reader读取端口，启动 TCP 连接，并将相同*bufio.Reader指定的字节数复制到stdout 。 全部带有错误处理。 对于具有如此严格的编码约定的语言，我认为这甚至不应该被允许。 不过，我想gofmt可以帮助解决这个问题。

对于具有如此严格的编码约定的语言，我认为这甚至不应该被允许。

用 Go 编写可恶的代码是可能的。 甚至可以将其格式化得非常糟糕； 只有强有力的规范和工具反对它。 Go 甚至有goto 。

在代码审查期间，我有时会要求人们将复杂的表达式分解为多个语句，并使用有用的中间名。 出于同样的原因，我会为深度嵌套的try做类似的事情。

这就是说：让我们不要太努力地取缔糟糕的代码，代价是扭曲语言。 我们还有其他保持代码整洁的机制，这些机制更适合那些从根本上涉及人类判断的事情。

用 Go 编写可恶的代码是可能的。 甚至可以将其格式化得非常糟糕； 只有强有力的规范和工具反对它。 Go 甚至有 goto。

在代码审查期间，我有时会要求人们将复杂的表达式分解为多个语句，并使用有用的中间名。 出于同样的原因，我会为深度嵌套的尝试做类似的事情。

这就是说：让我们不要太努力地取缔糟糕的代码，代价是扭曲语言。 我们还有其他保持代码整洁的机制，这些机制更适合那些从根本上涉及人类判断的事情。