On Thu, Aug 8, 2013 at 2:56 PM, David Jeske <[email protected]> wrote:
> On Aug 7, 2013 9:11 PM, "William ML Leslie" <[email protected]> > wrote: > > > Don't finally clauses interfere with this? > > > > I could guess at why you ask, but it's probably better if you say it. > > I interpret your suggestion to mean we install condition handlers which > run on the stack of the error, before stack unroll. They could decide to > capture the stack or not, because it remains above them. > No no. I'm questioning why you are trying to preserve the stack in the first place. > 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. > Yuck! What you are describing sounds suspiciously like downward exceptions, which is totally bad and semantically problematic. At the moment of raise, you have a series of stack frames that look like: F_main ... F_catch : F_0 ... F_n : F_raise At the moment of catch, the only remaining frames are: F_main ... F_catch That's it. I don't think any of the intermediate frames want any preservation at all. I think this whole discussion is confusing a debugging feature for a production performance problem, and that we are doing so primarily because CLR confuses them. Aside: there are much more efficient ways to implement stack capture than the way CLR does it. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
