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.
