defer file close on overridden variable - go

Question

I'm in the process of learning Go, so I try to write an app that gets some data from a JSON API and put it into a file. I wrote a function to check whether my file exists and if not to create it.
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)
}
}
my considerations are:
Is this a correct way of doing it?
Is a bad thing to call defer f.Close() when the file was not opened (by Open, Create, ...), should I call it only after the error check?
It's kinda related to previous question, assumming that file from the os.Open call does not need to be closed because an error was returned there is no need to assign results of os.Create to new variable and close it separatly, correct?
What to do when f.Close() fails, is there anything more to do except put some logs or ignore it?

Answer 1

I would say there are multiple "wrongs" in your approach.
First, if a function is defined to return an error along with other values, you should almost always first check for error and only attempt to use the other values if there was no error.
A well-known (but rare) exception are methods of the io.Reader and io.Writer interface which may return a non-zero number of bytes read/written and a non-nil error.
While your deferred call does not use the value assigned to f immediately, if the call to os.Open fails—and hence returns a non-nil error, the value assigned to f is actually undefined. Well, Go is not C, and to actually have it operate on truly non-initialized memory one has to go for great lengths (and use unsafe) but the most important fact is that most of the functions with multiple return values one of which is error, do not document any state the rest of the values will be if the error is not nil.
In particular, os.File is free to return any value at all as its first return value when its second one is a non-nil error.
Well, careful programmers usually won't do stupid things, and os.Open actually returns nil as its first return value when its second, error, is not nil.
But think what will happen if your call to os.Open fails: the variable f gets assigned the value nil, and then the deferred call to the function literal closed over that variable will attempt to call Open on the nil value.
Again, some methods defined on pointer receivers know what to do when their receiver is nil, but Open is not one of them and it will just blow up trying to dereference a nil pointer.
Yes, you appear to "compensate" for that with the subsequent call to os.Create which is not allowed to fail through the use of panic but this merely creates convoluted code. I think you have come up with this solution in order to not write two defer blocks—one for the succeeded os.Open and another—for the succeeded os.Create, but if I were you I'd just wrote a simple "open or create" helper which would return the same values as os.Open or os.Create do. Beleive it or not, Go already has one—read on ;-)
So, the correct usage pattern most of the time is
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()
// ...
}()
Second, it's not needed to employ try-open-then-create-if-not-exists approach: the os.Open and os.Create can be seen as simplified interfaces for the generalized os.OpenFile (which maps quite closely to the open(2) call of POSIX.
With the O_CREATE flag that function will automatically create the file if it does not exist, and as a bonus, that happens atomically with regard of the check (while your approach has a natural race with the filesystem: between the attempt to open the file and an attempt to create it some other process may create it making the second call fail).
As to your last question, the answer is "it depends":
If a file was opened for reading and you have successfully read all the (required) data from the file, an error while closing it does not mean you have lost anything and is actually not likely to happen. Logging it as a warning and continuing is OK in most cases.
If a file was opened for writing, failure to closing it may mean you may have lost some part of what was written to that file before the call to Close.
A common example of the call to Close failing is a file residing on a networked filesystem (like NFS or CIFS).
Exactly what should be the strategy to employ highly depends on the nature of the process which performed that operation: say, if you're writing an e-mail server, failure to store a message should result in giving up and properly communicating the problem to the sending client; if you're writing an interactive application you might ask the user what to do and may be allow them to re-try or change the file's location and then re-try or whatever.