我是否应该在使用 os.Open 时配合使用 log.Panic() 或 log.Fatal()？

本篇文章主要是结合我之前面试的各种经历和实战开发中遇到的问题解决经验整理的，希望这篇《我是否应该在使用 os.Open 时配合使用 log.Panic() 或 log.Fatal()？》对你有很大帮助！欢迎收藏，分享给更多的需要的朋友学习~

当我们有：

f, err := os.Open("no-file.txt")
if err != nil {
    log.Panic(err)
}
defer f.Close()

我认为使用 log.panic(err) 更有意义。正确的？ panic() 允许延迟 f.close() 执行，但 log.fatal() 阻止它。

或者如果找不到文件则不会打开？我想在这种情况下，我们使用 fatal 或 panic 是无关紧要的。对吗？

解决方案

log.Fatal() 应该很少在生产应用程序中使用（如果有的话），因为它会终止整个应用程序。 log.Panic() 执行日志后出现恐慌，这也是很少需要的。

许多示例使用它们（或者单个 panic(err) 调用）来使示例代码更短（让您专注于示例的内容），但在生产应用程序中应谨慎使用它们。相反，“正确”处理错误。这意味着特定于用例，您可以选择记录它并返回，或者返回一个新错误或执行其他操作，但只用它做一件事（仅处理一次）。请参阅 Writing good Golang code。

我更喜欢 log.Panic()。

log.Panic 与 log.Fatal 本质上是恐慌与 os.Exit(1)。

Exit比Panic更糟糕。它也使测试变得更加困难。处理执行os.Exit的代码要困难得多。通过recover来阻止测试中的panic非常简单。

所以，最好选择潜在损害较小的东西。

今天关于《我是否应该在使用 os.Open 时配合使用 log.Panic() 或 log.Fatal()？》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！