Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

doc: be more explicit about panic / recover & new goroutines #11832

Closed
derekperkins opened this issue Jul 23, 2015 · 4 comments
Closed

doc: be more explicit about panic / recover & new goroutines #11832

derekperkins opened this issue Jul 23, 2015 · 4 comments
Labels
Documentation Issues describing a change to documentation. FrozenDueToAge

Comments

@derekperkins
Copy link

I had some confusion over in Google Groups that recover would apply to any "descendant" goroutine panics, similar to try / catch statements in other languages. Neither the Go blog nor the spec is very explicit.

@dsymonds explained it very succinctly as "The recover builtin only applies to the stack frame that it is in, and each goroutine gets its own stack."

I've been working professionally in Go all day every day for over a year and am just learning this little tidbit, and otherwise consider myself fairly proficient, despite misunderstanding something so basic. I'd like to propose an addition to the spec explaining the difference between panic / recover and try / catch, or at a minimum adding @dsymonds' clarification.

@dsymonds dsymonds added the Documentation Issues describing a change to documentation. label Jul 23, 2015
@cespare
Copy link
Contributor

cespare commented Jul 23, 2015

But there's nothing in any of the docs or the spec that suggests some kind of parent/child relationship between goroutines, right?

@bradfitz bradfitz changed the title Be more explicit about panic / recover & new goroutines doc: be more explicit about panic / recover & new goroutines Jul 23, 2015
@ianlancetaylor
Copy link
Member

The spec is already clear on this, in its terse way. In http://golang.org/ref/spec#Handling_panics it 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." It goes on to explain when recover will work. There is nothing in the spec that says that recover will work on panic in a function that is not running in the same goroutine.

Somebody could write a blog entry or something, perhaps. Actually, there is already a blog entry: http://blog.golang.org/defer-panic-and-recover. It says "If the current goroutine is panicking, a call to recover will capture the value given to panic and resume normal execution."

So really I'm not sure what there is to do.

@derekperkins
Copy link
Author

I'm not saying that I was misled by the docs talking about parent / child relationships. Without even consciously thinking it, I associated the recover block with catch statements that almost every programmer learning Go is more familiar with than multiple returns. I don't think my misinterpretation is that uncommon for anyone coming from another language.

@rsc
Copy link
Contributor

rsc commented Aug 6, 2015

I appreciate your point, and I apologize for the confusion, but we can't update the docs for every possible confusion, and I haven't seen this come up much.

As Ian points out, the blog post already does state that recover only applies to panics in the current goroutine.

Regarding try/catch, contrasting with those would require assuming that readers know those details, which is something we'd rather not do - many will not. But perhaps more importantly, I'm not aware of any language in which try/catch handles exceptions in "child" threads. Certainly in C++, Java, and Python exception catching is limited to the current thread. So that's not actually a contrast.

@golang golang locked and limited conversation to collaborators Aug 5, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Documentation Issues describing a change to documentation. FrozenDueToAge
Projects
None yet
Development

No branches or pull requests

6 participants