为何在 main 函数中应该限制对 os.Exit 的调用次数？

积累知识，胜过积蓄金银！毕竟在Golang开发的过程中，会遇到各种各样的问题，往往都是一些细节知识点还没有掌握好而导致的，因此基础知识点的积累是很重要的。下面本文《为何在 main 函数中应该限制对 os.Exit 的调用次数？》，就带大家讲解一下知识点，若是你对本文感兴趣，或者是想搞懂其中某个知识点，就请你继续往下看吧~

我开始了一份新工作，我们被指示使用 Ubers Go 编码标准。我不确定他们的一项名为“退出一次”的指南：

如果可能，最好在 main() 中最多调用一次 os.Exit 或 log.Fatal。如果存在多个导致程序执行停止的错误情况，请将该逻辑放在单独的函数下并从中返回错误。

这难道不意味着将 main() 卸载到另一个函数 (run()) 中吗？这对我来说似乎有点多余。 Uber 的方法有什么好处？

正确答案

我不熟悉 uber 的整个 go 编码标准，但这个特定的建议是合理的。 os.Exit 的一个问题是它非常残酷地结束了程序，而不尊重任何挂起的延迟函数调用：

（我的重点）

但是，这些延迟的函数调用可能负责重要的清理任务。考虑 uber 的示例代码片段：

package main

func main() {
  args := os.args[1:]
  if len(args) != 1 {
    log.fatal("missing file")
  }
  name := args[0]

  f, err := os.open(name)
  if err != nil {
    log.fatal(err)
  }
  defer f.close()

  // if we call log.fatal after this line,
  // f.close will not be called.

  b, err := ioutil.readall(f)
  if err != nil {
    log.fatal(err)
  }

  // ...
}

如果 ioutil.readall 返回非零错误，则调用 log.fatal ；并且因为 log.Fatal calls os.Exit under the hood，对 f.close 的延迟调用将不会运行。在这种特殊情况下，情况并没有那么严重，但想象一下延迟调用涉及一些清理的情况，例如删除文件；你会让你的磁盘处于不干净的状态。有关该主题的更多信息，请参阅 episode #112 of the Go Time podcast，其中讨论了这些注意事项。

因此，最好避免在程序“深处”使用 os.exit、log.fatal 等。 uber 的 go 编码标准中描述的 run 函数允许延迟调用在程序执行结束之前按预期运行（可能带有非零状态代码）：

package main

func main() {
  if err := run(); err != nil {
    log.Fatal(err)
  }
}

func run() error {
  args := os.Args[1:]
  if len(args) != 1 {
    return errors.New("missing file")
  }
  name := args[0]

  f, err := os.Open(name)
  if err != nil {
    return err
  }
  defer f.Close()

  b, err := ioutil.ReadAll(f)
  if err != nil {
    return err
  }

  // ...
}

这种方法的另一个好处是，虽然 main 函数本身不容易测试，但您可以在考虑可测试性的情况下设计这样的 run 函数；有关该主题，请参阅 Mat Ryer's blog post。

今天关于《为何在 main 函数中应该限制对 os.Exit 的调用次数？》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！