Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
spec: panicking corner-case semantics #10458
A few corner-cases regarding panicking that I noticed in the Go spec:
1) What happens if a panic occurs while a goroutine is already panicking?
Gc/gccgo seem to allow recursive panicking and recovering: http://play.golang.org/p/tBkwgyzmuT
But if a deferred function panics without any recovery, then the original panic is lost: http://play.golang.org/p/KqwGiWGMAx
2) The Go spec says "The return value of recover is nil if any of the following conditions holds: [...] recover was not called directly by a deferred function."
Gc/gccgo though seem to also have recover return nil in deferred functions if they were executed because of normal (i.e., non-panicking) function return: http://play.golang.org/p/a-fl_9Gga0
3) The Go spec says "Suppose a function G defers a function D that calls recover and a panic occurs in a function on the same goroutine in which G is executing. [...] If D returns normally, without starting a new panic, the panicking sequence stops."
Nit: I think the intention here is understood, but the wording could probably be improved somewhat. As quoted in item 2 above, the spec later explicitly refers to deferred functions that "directly" call recover. Omitting "directly" here suggests that indirect calls to recover should still stop the panicking sequence, but they'll return nil instead of the panic value.
Unfortunately I don't understand what you are suggesting. To me the spec seems accurate and complete.
You seem to suggest that we should omit "directly," but that would be a clear change in behaviour. Indirect calls to recover do not stop the panicking sequence. They simply return nil and the panic continues.
@ianlancetaylor Are you referring to just item 3, or you think the spec is accurate and complete for the first two items I listed too?
Rephrasing my concern about the wording in item 3, currently the spec seems to admit this behavior for recover:
The nit I see is the stop-panicking logic and the what-value-is-returned logic are separately described with slightly different wording.
I think by reorganizing the section a bit, it could be clearer that the correct behavior is something like: