Will this variable be set in `defer`

[Antoine Grondin]

I was thinking of this pattern to check for the errors of closer.Close statements:

http://play.golang.org/p/L8OGmIJFCz

Is `closeErr` going to be set as expected if `conn.Close()` returns an error?  If so, is this pattern already known/used?  If not, can I claim it and become rich and famous?

[Antoine Grondin]

I failed at making a proper snippet, forgetting to cleanup my original code to make a nice example.  Here's a proper one if the previous link disturbed you:

http://play.golang.org/p/O39cATqsmH

[Kevin Malachowski]

No, because the return effectively evaluates the return value and stores it before any defers execute. But using named parameters will work because they provide access to the actual return values:

http://play.golang.org/p/7YEcYaS3II

[Matthew Kane]

Not as written: http://play.golang.org/p/0q8cG2Ym-5

You can mutate a named return value, however:
http://play.golang.org/p/l5Rt4f34if

Even with a hardcoded "return nil" this works:
http://play.golang.org/p/T_lzBtJL1x

> --
> 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...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.



--
matt kane
twitter: the_real_mkb / nynexrepublic
http://hydrogenproject.com

[Antoine Grondin]

To expand, consider if `err` was set by another operation before the return call.  Say, a `conn.Read` failed.  Then returning, I would not want a following `Close` fail to hide the original error.  So I came up with this:

http://play.golang.org/p/tLL_tobUzr

However it's not very elegant.  Any thought on how to do this better?

Cheers, 

--

Antoine Grondin

Live long and prosper

[Antoine Grondin]

dsal on IRC suggested http://play.golang.org/p/RjWJlPE5jY, which is awkwardly something I used before.  I guess that solves my last question.

Cheers, 

--

Antoine Grondin

Live long and prosper

[Kevin Malachowski]

Note that if you do this (or this sort of thing) often you can always structure the error checking code into another function similar to this: http://play.golang.org/p/EKQZfiw0_K

Even if you keep it the error checking as a closure like you had it, you can still simplify some of your code if you invert your conditional and use the simple statement-condition "if" that go has (like the CloseWithErrors function in my example)