`Close()` should be `Close() error`

[runcom]

Anything against having {Image,ImageSource,ImageDestination}.Close() implement io.Closer https://golang.org/pkg/io/#Closer? (which basically is adding an error return). I think we would have this for #63 also.

ref: https://github.com/containers/image/blob/master/types/types.go#L98

@mtrmac wdyt?

[mtrmac]

I had an error return in there, but then removed it because it seemed to be a Potemkin village in most users.

Everyone is all too eager to do

defer somevariable.Close()

ignoring the error, instead of writing something like

defer func() { if e := somevariable.Close(); e != nil && err == nil { err = e } }()

to propagate the error.

So, would there be a practical benefit? Are there any interfaces which would benefit from implementing io.Closer (without Reader/Writer)? There may well be, I just haven’t encountered them. I am still fairly new to the Go ecosystem.

Arguably we should allow reporting the errors, which at least gives callers the option to handle failures correctly.

---

The correctly-propagating-error handling could be actually done reasonably nicely with

func CloseWithError(c io.Closer, pe *error) {
  if e := c.Close(); e != nil && *pe == nil {
    *pe = e
 }
}

and

   defer CloseWithError(somevariable, &err)

This seems like such a commonly needed idiom that it should already exist somewhere in the standard library, but I can see this neither in io nor in io/ioutil.

[runcom]

I had an error return in there, but then removed it because it seemed to be a Potemkin village in most users.

Everyone is all too eager to do

defer somevariable.Close()
ignoring the error, instead of writing something like

defer func() { if e := somevariable.Close(); e != nil && err == nil { err = e } }()
to propagate the error.

So, would there be a practical benefit? Are there any interfaces which would benefit from implementing io.Closer (without Reader/Writer)? There may well be, I just haven’t encountered them. I am still fairly new to the Go ecosystem.

Arguably we should allow reporting the errors, which at least gives callers the option to handle failures correctly.

even if people tends to do that no-err-check-defer-close it doesn't meant we should code to prevent that. Types and returns are documented and it's up to who implements this library to check errors if they think so (not questioning the rightness to not do that).

The correctly-propagating-error handling could be actually done reasonably nicely with

func CloseWithError(c io.Closer, pe *error) {
if e := c.Close(); e != nil && *pe == nil {
*pe = e
}
}
and

defer CloseWithError(somevariable, &err)
This seems like such a commonly needed idiom that it should already exist somewhere in the standard library, but I can see this neither in io nor in io/ioutil.

CloseWithError(err error) it's a different pattern in Go - it means Close the underlying Writer/Closer assigning the given error somewhere to be later used.

So, would there be a practical benefit? Are there any interfaces which would benefit from implementing io.Closer (without Reader/Writer)? There may well be, I just haven’t encountered them. I am still fairly new to the Go ecosystem.

I believe so - it's a least future proof since many libraries and tools abstract writers and readers (and generally Closer(s)).

[mtrmac]

CloseWithError(err error) it's a different pattern in Go
Yeah, you know how I am with naming :) Just wanted to demonstrate the context.

ACK, let’s change that whenever someone has copious free time.

[runcom]

ACK, let’s change that whenever someone has copious free time.

yeah, wasn't mean as stuff to be done soon

[erikh]

I'll do it

[erikh]

FWIW, i think closewitherror is typically needed on Write/ReadClosers but not closers themselves -- it's typically used to propagate to io.Copy and similar.

[mtrmac]

Do not get hung up on the CloseWithError name here, this has nothing to do with Pipe{Reader.Writer}.CloseWithError; it’s just a name collision with that five-line helper function I have suggested above to do correct error propagation if Close() can fail. That five-line helper can be named anything else.