Yes; it seemed to me that the return statement would get evaluated even
after a panic. I thought of it as a special case of a deferred context -
confused.
Thank you very much;
On Friday, August 26, 2016 at 12:11:03 PM UTC+4:30, Axel Wagner wrote:
>
> I'd think, the spec is reasonably unambiguou
To me this works as expected.
In both your versions, the return statement in Recover() is not even
reached since the call to f panics. You recover from the panic in your
defer statement and assign the err variable your error value.
Since in your first version, that variable is not returned, you
I'd think, the spec is reasonably unambiguous, if not very explicit. The
second version works, because of
For instance, if the deferred function is a function literal and the
> surrounding function has named result parameters that are in scope within
> the literal, the deferred function may access
There deferred function here has not any return value - to get discarded.
It rather assigns a value to the *closure* *err* variable.
Since a defer statement "*invokes a function whose execution is deferred to
the moment the surrounding function returns*", so I expected the *err*
variable should
I put your code snippet in the playground for easier sharing:
https://play.golang.org/p/ZvuNwjS7ZF
I think the spec has the answer you're looking for regarding how named
result parameters are handled during a panic.
https://golang.org/ref/spec#Defer_statements
Specifically the sentence:
> If t
