Re: [go-nuts] Deferring a close that can fail
>
> 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 only if Open is success. I
> usually prefer the latter.
>
> --
> { "github":"github.com/shuLhan", "site":"kilabit.info" }
>
You and I agree: my code snippit will panic if the open fails, or if (the
open suceeds && the close fails)
--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.
Re: [go-nuts] Deferring a close that can fail
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 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 >> usually prefer the latter. > > You and I agree: my code snippit will panic if the open fails, or if (the > open suceeds && the close fails) > > --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. > -- 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.
Re: [go-nuts] Deferring a close that can fail
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 > usually prefer the latter. > You and I agree: my code snippit will panic if the open fails, or if (the open suceeds && the close fails) --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.
Re: [go-nuts] Deferring a close that can fail
> > 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 and I agree: my code snippit will panic if the open fails, or if (the open suceeds && the close fails) --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.
Re: [go-nuts] Deferring a close that can fail
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! > > Not in general, I think. Suppose we have something along the lines of UPDATE weather SET observations = observations + 1; We exec this statement to the database, and we issue a COMMIT. But before we receive the result of that commit, the program fails, aborts and closes the connection. At this point whether or not the above statement was executed is unknown. The database is still consistent in both states, but we have no real way of knowing, save if we make a unique tag for each observation and test if the observation was admitted later on. If you then reread the input and commit it in the same way, you have just counted the observation twice, which is almost surely not what you want to do. The problem is akin to having a buffer with written data, but before having synced it to disk. The underlying problem is that if you have ephemeral data handling, such as overwriting data or having a counter, you are throwing away information. And in general, such computation is not reversible which leads to all sorts of fun things. If you have persistent data, such as an append-only log, then you are able to stitch together what happened and then remedy the problem. It also suggests it is generally safer to write a new file to disk and then eventually move said file on top of the existing one. In short, making this a safe semantics requires one to look at the specific problem at hand and make sure there is a way to recover. You are generally guaranteed a point-in-time consistent state of your system, if the database is worth its salt. But from there on, you are on your own to ensure things. -- J. -- 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.
Re: [go-nuts] Deferring a close that can fail
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
> 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.
>
> Is there an idiomatic way to address this?
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.
--
{ "github":"github.com/shuLhan", "site":"kilabit.info" }
--
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.
Re: [go-nuts] Deferring a close that can fail
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 situation? Is panicking a problem
for you and you would like to make it go away?
I usually perform case distinction in order to include the error
information of any error that might have occurred during the body of the
function. Otherwise, if you just override the error with the error at the
close time, the user is completely at loss what actually happened. Here is
a snippet:
func someFunc() (err error) {
ifDB, message, err := OpenInflux(server, debug)
if err != nil {
return
}
defer func() {
errClose = ifDB.Close()
switch {
case err == nil && errClose != nil:
err = fmt.Errorf("failed to close the database: %s",
errClose.Error())
case err != nil && errClose != nil:
err = fmt.Errorf(
"failed to close the database (%s) after the error occurred: %s",
errClose, err)
}
}()
// ... some more code that might also set err
}
Cheers Marko
--
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.
[go-nuts] Deferring a close that can fail
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.
