延迟变量覆盖后的文件关闭

亲爱的编程学习爱好者，如果你点开了这篇文章，说明你对《延迟变量覆盖后的文件关闭》很感兴趣。本篇文章就来给大家详细解析一下，主要介绍一下，希望所有认真读完的童鞋们，都有实质性的提高。

我正在学习 go，所以我尝试编写一个应用程序，从 json api 获取一些数据并将其放入文件中。我编写了一个函数来检查我的文件是否存在，如果不存在则创建它。

func ensureFileExists(filePath string) {
    f, err := os.Open(storageFile)
    defer func() {
        err := f.Close()
        if err != nil {
            fmt.Printf("fail to close file %q, error: %q", filePath, err)
            return
        }
        fmt.Printf("file %q closed", filePath)
    }()
    if err != nil {
        if os.IsNotExist(err) {
            f, err = os.Create(storageFile)
            if err != nil {
                panic(err)
            }
            return
        }
        panic(err)
    }
}

我的考虑是：

1. 这是正确的做法吗？
2. 在文件未打开时调用 defer f.close() 是一件坏事（通过 open、create，...），我应该仅在错误检查后调用它吗？
3. 这与上一个问题有点相关，假设 os.open 调用中的文件不需要关闭，因为返回了错误，因此不需要将 os.create 的结果分配给新变量并单独关闭它，正确？
4. 当 f.close() 失败时该怎么办，除了放一些日志或忽略它之外还有什么可做的吗？

解决方案

我想说你的方法有多个“错误”。

首先，如果函数被定义为与其他值一起返回错误，那么您几乎应该始终首先检查错误，并且只有在没有错误的情况下才尝试使用其他值。
一个众所周知（但很少见）的例外是 io.reader 和 io.writer 接口的方法，它们可能返回非零字节数的读/写和非 nil 错误。 p>

虽然您的延迟调用不会立即使用分配给 f 的值，但如果对 os.open 的调用失败，并因此返回非 nil 错误，则分配给 f 的值实际上是 未定义。 嗯，go 不是 c，要真正让它在真正的未初始化内存上运行，必须花很大的力气（并使用 unsafe），但最重要的事实是大多数函数如果有多个返回值，其中之一是 error，请不要记录任何声明，如果 error 不是 nil，则其余值将是。
特别是，当 os.file 的第二个返回值是非 error 时，os.file 可以自由地返回任何值作为其第一个返回值。

好吧，细心的程序员通常不会做傻事，而且 os.open 实际上返回 nil 作为其第一个返回值，而第二个返回值 error 不是 nil。
但想想如果对 os.open 的调用失败会发生什么：变量 f 被分配值 nil，然后对该变量关闭的函数文字的延迟调用将尝试对 nil 值调用 open。

同样，指针接收器上定义的一些方法知道当接收器是 nil 时该怎么做，但 open 不是其中之一，它只会在尝试取消引用 nil 指针时爆炸。

是的，您似乎通过随后对 os.create 的调用来“补偿”这一点，不允许通过使用 panic 来失败，但这只会创建复杂的代码。我认为您提出这个解决方案是为了不编写两个 defer 块（一个用于成功的 os.open ，另一个用于成功的 os.create ），但如果我是你，我只会写一个简单的“打开或create”帮助器，它将返回与 os.open 或 os.create 相同的值。不管你相信与否，go 已经有了一个——继续阅读 ;-)

所以，大多数时候正确的使用模式是

f, err := os.Open(...)
if err != nil {
  // Handle error
  return ...
}
// At this point f is known to be in a good state
defer func() {
  err := f.Close()
  // ...
}()

其次，不需要采用 try-open-then-create-if-not-exists 方法：os.open 和 os.create 可以被视为广义 os.OpenFile 的简化接口（它非常接近地映射到open(2) call of POSIX。
使用 o_create 标志，该函数将自动创建文件（如果该文件不存在），并且作为奖励，这种情况在检查方面以原子方式发生（而您的方法与文件系统存在自然竞争：在尝试打开文件和尝试创建它的其他进程可能会创建它，从而导致第二次调用失败）。

关于你的最后一个问题，答案是“这取决于”：

• 如果打开一个文件进行读取，并且您已成功读取该文件中的所有（必需）数据，则关闭该文件时出现错误并不意味着您丢失了任何内容，而且实际上不太可能发生这种情况。在大多数情况下，将其记录为警告并继续即可。
• 如果打开文件进行写入，则无法关闭该文件可能意味着您可能丢失了在调用 clos​​e 之前写入该文件的部分内容。 调用 clos​​e 失败的一个常见示例是驻留在网络文件系统（如 nfs 或 cifs）上的文件。
  究竟应该采用什么策略，很大程度上取决于执行该操作的过程的性质：比如说，如果您正在编写一个电子邮件服务器，则存储消息失败应该导致放弃并将问题正确地传达给发送客户端；如果您正在编写交互式应用程序，您可能会询问用户要做什么，并可能允许他们重试或更改文件的位置，然后重试或进行其他操作。

理论要掌握，实操不能落！以上关于《延迟变量覆盖后的文件关闭》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！