Why does a call to defer func() { recover() }()
successfully recover a panicking goroutine, but a call to defer recover()
not?
As an minimalistic example, this code doesn't panic
package main
func main() {
defer func() { recover() }()
panic("panic")
}
However, replacing the anonymous function with recover directly panics
package main
func main() {
defer recover()
panic("panic")
}
The Handling panic section mentions that
Two built-in functions,
panic
andrecover
, assist in reporting and handling run-time panicsThe
recover
function allows a program to manage behavior of a panicking goroutine.Suppose a function
G
defers a functionD
that callsrecover
and apanic
occurs in a function on the same goroutine in whichG
is executing.When the running of deferred functions reaches
D
, the return value ofD
's call torecover
will be the value passed to the call of panic.
If D returns normally, without starting a new panic, the panicking sequence stops.
That illustrates that recover
is meant to be called in a deferred function, not directly.
When it panic, the "deferred function" cannot be the built-in recover()
one, but one specified in a defer statement.
DeferStmt = "defer" Expression .
The expression must be a function or method call; it cannot be parenthesized.
Calls of built-in functions are restricted as for expression statements.With the exception of specific built-in functions, function and method calls and receive operations can appear in statement context.
Quoting from the documentation of the built-in function recover()
:
If recover is called outside the deferred function it will not stop a panicking sequence.
In your second case recover()
itself is the deferred function, and obviously recover()
does not call itself. So this will not stop the panicking sequence.
If recover()
would call recover()
in itself, it would stop the panicking sequence (but why would it do that?).
Another Interesting Example:
The following code also doesn't panic (try it on the Go Playground):
package main
func main() {
var recover = func() { recover() }
defer recover()
panic("panic")
}
What happens here is we create a recover
variable of function type which has a value of an anonymous function calling the built-in recover()
function. And we specify calling the value of the recover
variable to be the deferred function, so calling the builtin recover()
from that stops the panicing sequence.
An observation is that the real problem here is the design of defer
and thus the answer should say that.
Motivating this answer, defer
currently needs to take exactly one level of nested stack from a lambda, and the runtime uses a particular side effect of this constraint to make a determination on whether recover()
returns nil or not.
Here's an example of this:
func b() {
defer func() { if recover() != nil { fmt.Printf("bad") } }()
}
func a() {
defer func() {
b()
if recover() != nil {
fmt.Printf("good")
}
}()
panic("error")
}
The recover()
in b()
should return nil.
In my opinion, a better choice would have been to say that defer
takes a function BODY, or block scope (rather than a function call,) as its argument. At that point, panic
and the recover()
return value could be tied to a particular stack frame, and any inner stack frame would have a nil
pancing context. Thus, it would look like this:
func b() {
defer { if recover() != nil { fmt.Printf("bad") } }
}
func a() {
defer {
b()
if recover() != nil {
fmt.Printf("good")
}
}
panic("error")
}
At this point, it's obvious that a()
is in a panicking state, but b()
is not, and any side effects like "being in the first stack frame of a deferred lambda" aren't necessary to correctly implement the runtime.
So, going against the grain here: The reason this doesn't work as might be expected, is a mistake in the design of the defer
keyword in the go language, that was worked around using non-obvious implementation detail side effects and then codified as such.
来源:https://stackoverflow.com/questions/29518109/why-does-defer-recover-not-catch-panics