Somewhat new to Go, so please be patient... I had a bug that arose from failing to check the error returned from a function call, so ran a linter to see where else I might be doing that. It flagged the deferred file close in this bit inside an HTTP handler function. file, header, err := r.FormFile("photo") if err != nil { h.app.errorJSON(w, http.StatusBadRequest, fmt.Errorf("failed to get file: %w", err).Error()) return } defer file.Close() As I started addressing it, I saw some problems. In the case of an HTTP handler, there is no returned error to change, and we've already written output to the user, so can't call errorJSON again. Even in another function that uses a named Error for return, it shows that the common pattern of "open file; defer its closing; do some work" is oversimplified. But that's the classic example that almost every beginning Go tutorial uses to show the power of defer.…