Re: [go-nuts] Re: Deferring a close that can fail

2019-03-21 Thread roger peppe
On Thu, 21 Mar 2019 at 16:14, wrote: > Two things to note about this. > > First, if the "everything else" deferred to might include a return > statement, then this could result in the same "silent failure" behavior. > Yup, don't do that :) > Secondly - use this pattern with great caution. It

Re: [go-nuts] Re: Deferring a close that can fail

2019-03-21 Thread jake6502
Two things to note about this. First, if the "everything else" deferred to might include a return statement, then this could result in the same "silent failure" behavior. Secondly - use this pattern with great caution. It is critical to confirm that a double close on ifDB is explicitly

[go-nuts] Re: Deferring a close that can fail

2019-03-21 Thread Manlio Perillo
On Thursday, March 21, 2019 at 10:41:05 AM UTC+1, Amnon Baron Cohen wrote: > > The idiomatic Go way is to write > >defer ifDB.Close() > > Simple is better than clever. > > + Readability does matter. > > Do you think logging the possible error from Close is clever? If you want readability you

Re: [go-nuts] Re: Deferring a close that can fail

2019-03-21 Thread roger peppe
This issue is why I like having idempotent close. Do: defer ifDB.Close() but also, after everything else is complete, do: if err := ifDB.Close(); err != nil { handle error case } That way if you return early on error your connection is still closed, but you can still write

[go-nuts] Re: Deferring a close that can fail

2019-03-21 Thread Amnon Baron Cohen
The idiomatic Go way is to write defer ifDB.Close() Simple is better than clever. + Readability does matter. And in situations where you really need to check that the connection was successfully closed, and you have a workable scheme for recovering from this situation, then write a

Re: [go-nuts] Re: Deferring a close that can fail

2019-03-20 Thread David Collier-Brown
Hmmn, Donald Knuth would not have liked this (;-)) Knuthput, if I remember correctly, didn't have "fail on close()" semantics. > > --dave -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails

Re: [go-nuts] Re: Deferring a close that can fail

2019-03-20 Thread David Collier-Brown
Looks as if "Close()-like things" all fall into two categories - the usual horrid one, in which you can discover too late something didn't complete, or - the trivial case, in which the pre-close operations are transactional and xxx.Close() only ever returns nil Which means I have

Re: [go-nuts] Re: Deferring a close that can fail

2019-03-20 Thread Manlio Perillo
On Wednesday, March 20, 2019 at 10:53:44 PM UTC+1, Kurtis Rader wrote: > > On Wed, Mar 20, 2019 at 2:08 PM Manlio Perillo > wrote: > >> Note from the Linux close documentation: >> >> Not checking the return value of close() is a common but nevertheless >> serious programming error. It is quite

Re: [go-nuts] Re: Deferring a close that can fail

2019-03-20 Thread Kurtis Rader
On Wed, Mar 20, 2019 at 2:08 PM Manlio Perillo wrote: > Note from the Linux close documentation: > > Not checking the return value of close() is a common but nevertheless > serious programming error. It is quite possible that errors on a previous > write (2)

[go-nuts] Re: Deferring a close that can fail

2019-03-20 Thread Manlio Perillo
On Wednesday, March 20, 2019 at 12:57:51 AM UTC+1, David Collier-Brown wrote: > > It's a known bad thing to defer a close for anything buffered, as > discussed at https://www.joeshaw.org/dont-defer-close-on-writable-files/ > but some constructs lack a Sync() call. > > Note from the Linux close