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

2019-03-20 Thread David Collier-Brown
> > On Wednesday, March 20, 2019 at 1:44:23 AM UTC-4, Shulhan wrote: Any Close on file or connection should be called only if only the > call to Open function or method success. > > You have two options here: either you remove the panic when Close is > error (only logging it) or call Close

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

2019-03-20 Thread Robert Engels
The update statement is fine as long as any data sources participate in an XA transaction. This is bar the simplest solution but may not meet performance constraints which is why people use other techniques. > On Mar 20, 2019, at 4:13 PM, David Collier-Brown wrote: > > > > > > 4:12

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

2019-03-20 Thread David Collier-Brown
4:12 PM (less than a minute ago) > Any Close on file or connection should be called only if only the > call to Open function or method success. > > You have two options here: either you remove the panic when Close is > error (only logging it) or call Close only if Open is success. I >

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

2019-03-20 Thread David Collier-Brown
> > Any Close on file or connection should be called only if only the > call to Open function or method success. > > You have two options here: either you remove the panic when Close is > error (only logging it) or call Close only if Open is success. I > usually prefer the latter. > You

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

2019-03-20 Thread Jesper Louis Andersen
On Wed, Mar 20, 2019 at 12:57 AM David Collier-Brown wrote: > Is there an idiomatic way to address this? I ended up reading influxDB > code and doing all sorts of deranged safety-critical-system DFAs to > reassure myself this will actually work, but every time I do that, my brain > hurts! > >

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

2019-03-19 Thread Shulhan
On Tue, 19 Mar 2019 16:57:51 -0700 (PDT) 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. > > For example, I have code like >

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

2019-03-19 Thread Marko Ristin-Kaufmann
Hi Dave, Separate logic makes sure I have passed the point at which the data is > committed before I commit my reading of input, so eventually the data will > be reread and rewritten. > I don't understand fully what you mean here. Maybe you could write a snippet of pseudo-code to illustrate the

[go-nuts] Deferring a close that can fail

2019-03-19 Thread David Collier-Brown
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. For example, I have code like ifDB, message, err := OpenInflux(server, debug) if err != nil {