> How would you resume execution at the panic point? You invert it: rather than panicking, then continuing from the panic point if things recover, you proceed,

> How would you resume execution at the panic point? You invert it: rather than panicking, then continuing from the panic point if things recover, you proceed, only panicking to perform a transfer of control. Interestingly, this is what Lisp does: SIGNAL[0] (the most primitive function) just looks for applicable handlers and calls them from most- to least-recent; this means that if a handler transfers control (panics, in Go terms) then the condition has been handled; if not, SIGNAL just returns NIL; ERROR[1] does the same thing, but calls INVOKE-DEBUGGER if no handler transfers control; CERROR[2] is like ERROR, but it adds a CONTINUE restart, which just lets control resume. It’s possible to implement this same structure in Go: conditions.Signal() would search for applicable handlers and execute them in order; if control transfers then it’d never return; conditions.Error() would invoke one or more handlers, or the debugger, and would never return; conditions.ContinuableError() would invoke one or more handlers, or the debugger, but might return. The key is that it’s possible to execute a restart in the dynamic context of the signalling function (via use of Go’s context.Context), and only rewind the stack when you don’t need to go back down it. I think — I’ve not yet implemented it! 0: http://www.lispworks.com/documentation/lw71/CLHS/Body/f_signal.htm http://www.lispworks.com/documentation/lw71/CLHS/Body/f_sign... 1: http://www.lispworks.com/documentation/lw71/CLHS/Body/f_error.htm http://www.lispworks.com/documentation/lw71/CLHS/Body/f_erro... 2: http://www.lispworks.com/documentation/lw71/CLHS/Body/f_cerror.htm http://www.lispworks.com/documentation/lw71/CLHS/Body/f_cerr...