> The only sensible thing would be to run all of them; local "break" > even does that in ES3.
Yes. > Of course that raises the question of what happens if a "break" whose > matching activation frame is no longer live would generate an error > but a finally clause would have caught and diverted it. Here's roughly the semantics of return-to-label: - return-to-label first checks to see if the label is live on the stack - if not, it raises an exception from the point where the return was attempted - but if so, it attempts to unwind the stack to the point where the label was executed, passing through any intervening finally clauses - if any of the finally clauses has its own non-local exit, this interrupts and aborts the unwinding Thank you for pointing out, though, that try/catch isn't so easily defined on top of return-to-label, since it still needs special handling for finally. The options are either to define a lower-level primitive underlying try/finally (akin to Scheme's dynamic-wind), or to leave exceptions -- or at least try/finally -- as primitive. I lean towards the latter; dynamic-wind is a subtle beast. [For those interested in dynamic-wind, Flatt et al's ICFP 07 paper has a nice investigation into its semantics: http://www.cs.utah.edu/plt/publications/icfp07-fyff.pdf] Dave _______________________________________________ Es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
