Hello,
I'm working on a GUI library, and one of the facilities provided is a way
to execute code on the GUI thread. The call site is pretty simple:
err := Do(func() error {
// Inside this closure, we will be executing only on the GUI thread.
_, err := fmt.Println("Hello.")
// Return the error (if any) back to the caller.
return err
})
Internally, the package handles marshalling the callback to the GUI thread
where is it called, and then marshalling the error value back to the
callee. The question is what should be done if the callback panics?
I'm confident that the panic needs to be recovered on the GUI thread, and
then marshalled back to the callee. This is easy to do, as the panic can
be wrapped in a custom error. For the callee, however, I'm not sure of the
ideal behaviour. I'd like to preserve the semantics of the panic, which
would be calling panic on the caller's goroutine to restart unwinding the
stack. However, the resulting stack trace would point to the wrong
location.
1) Are there any opinions on whether or not calling panic on the caller's
thread is worthwhile, or is returning a PanicError a better?
2) Whether or not panic is called on the caller's thread, is there a way to
capture the stack trace for the original panic? The information must be
available in the runtime, since if there is no recover, the runtime will
print a stacktrace from the original location, but I did not see a way to
access the data. Otherwise, there may be very little information to help
with debugging.
Robert
--
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
