On Thu, Aug 8, 2013 at 5:19 PM, William ML Leslie < [email protected]> wrote:
> > If we wish to preserve that stack for future handlers, no handler can be > allowed to set the stack pointer (unroll) unless it is ending the exception > propagation. This means generated code in handlers needs to reference > captured stack contents without using the stack pointer, because it runs > down in the stack of the error. > > Yes, that is what I was getting at. > > You correctly point out that such an implementation requires bundling a > closure or something for finally (or except) allowing it to use variables > elsewhere in the stack. That was already necessary for exception handlers, > because they need to know the value to set the sp if they handle the > exception. > This "condition handler" method would require some stack-trickiness in the case of the CLR, as they use stack-walks as a security mechanism. The security mechanism would need to see the condition handlers running in the correct security context. This issue doesn't seem insurmountable. > I guess, if in doubt, assume that those before were smarter than you. I > think it sounds like a fun technique, which even allows you to replace an > exception raise with a value, coroutine style. But maybe it is an > experiment for the future, and preserving the traceback should be done in > some other means. > I'm curious to hear Shap's wisdom about why this condition handler mechanism is perilous... other than the obvious difficulty maintaining sane condition handler closure and handler stack capture.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
