On Fri, Jan 18, 2019 at 8:59 AM Robert Johnstone
<r.w.johnst...@gmail.com> wrote:
>
> 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?
In most cases I think it is preferable to rethrow the panic, via something like
if r := recover(); r != nil {
myErr, ok := r.(myErrorType)
if !ok {
panic(r)
}
...
}
> 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.
Deferred functions run in the stack of the panic, so to capture a
stack trace at the point of the panic just call runtime/debug.Stack().
But I agree that there is no convenient way to attack that stack trace
to the rethrown panic. If we adopt the "errors as values" design
draft
(https://go.googlesource.com/proposal/+/master/design/go2draft-error-inspection.md)
then perhaps we could define a standard error type that wraps a
rethrown value with a stack trace.
Ian
--
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
