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 {
// If this fails, fail fast so we notice
panic(fmt.Errorf("failed to open and ping influxDB, %s %v",
message, err))
}
defer func() {
err = ifDB.Close()
if err != nil {
// This may be a harmless, very bad thing
panic(fmt.Errorf("failure closing connection to
influxDB, %v", err))
}
}()
which closes an influxDB database, but will panic if the close fails.
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. Nevertheless, this is exceedingly complex, and the
comment sums it up: "a harmless, very bad thing".
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!
--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 from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
