Defer panic caused by child goroutine

[bsr]

If I start a go routine to execute some function, and if it panics, is there a reliable way to recover it in the parent (main) go routine.

In this version, defer is inside the new go routine 

http://play.golang.org/p/QY58r2T-Gb

If I move it out to the main go routine, I see the the defer called, but not sure it is correct. 

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

The stack trace is still written and needed a timeout to see the defer statement. 

so, only reliable way is to defer in the child go routine, and return an error from there. Then capture it in parent?

Thanks.

[Kyle Lemons]

On Wed, Oct 9, 2013 at 1:20 PM, bsr <bsr...@gmail.com> wrote:

If I start a go routine to execute some function, and if it panics, is there a reliable way to recover it in the parent (main) go routine.

You can construct such a mechanism (defer a function that sends on a channel or something), though generally that would seem to be to indicate a potential problem elsewhere in the design.

 

In this version, defer is inside the new go routine 

http://play.golang.org/p/QY58r2T-Gb

If I move it out to the main go routine, I see the the defer called, but not sure it is correct. 

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

The stack trace is still written and needed a timeout to see the defer statement. 

so, only reliable way is to defer in the child go routine, and return an error from there. Then capture it in parent?

You can't catch a panic that is happening in another goroutine.  In the second example, your defer is not in the panicing goroutine.

 

Thanks.

--
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.

[bsr]

Thanks Kyle. So, deferring in the child goroutine, and send an error across to the parent is the right, straightforward and easy, correct?

Thanks again for your help.

[Kevin Gillette]

It's pretty much the only approach to do what you want. net/http, for example, just catches panics in each goroutine that it spawns, and logs those, but doesn't attempt to fan those into the main goroutine. Note that if you don't generate a stack trace in the goroutine from which the panic occurred, then the best you can do is get a stack dump of all goroutines; if the recovered-panic goroutine terminates after passing the error to main, but before main can generate the "all goroutines" stack trace, then the panicked goroutine will not be included in that output; since error values don't implicitly contain stack trace information, at that point, you'd have an error with absolutely no context (assuming that an error was even passed to the panic call), which means it'd be virtually worthless for debugging purposes, unless you explicitly stuff a stack trace into the error that you pass on to main.

Go's approach to panics is that they be used only for truly exceptional problems (such as divide by zero errors, array bounds violations, or clear misuse of an API by the application programmer); the accepted approach when this happens is to have the panic either kill the program, or at least be logged quite loudly, so that the problem can be fixed -- panics shouldn't be considered to be part of the normal operation of a correctly written/functioning program.

[bsr]

Thanks Kevin for explaining in detail. I had an index out of bound exception, and which was thrown to the client. I was deferring a function in main routine so that it does not expose the internals to the user. When the panic was in child, the defer didn't catch it. That was the context of my question. Anyway, I will catch it in the child routine, and return it as an error to the main program. Thanks to both of you for confirming it.