On 8 August 2013 12:29, David Jeske <[email protected]> wrote: > On Wed, Aug 7, 2013 at 6:35 PM, William ML Leslie > <[email protected]> wrote: >> >> Both you and Bennie seem to be saying, effectively: >> >> "The handler probably knows if it needs a filled-in stack trace or not" >> >> and you want to be able to communicate that to the raise statement >> (which should probably be polymorphic on this condition). > > > Actually, I was saying that I think the reason we see more expensive throw > is because they are preserving stack-frame-info before it's destroyed. I > think this might be a harder problem than you're suggesting... > > The top-level handler definitely wants a stack backtrace, but you don't know > whether you're going to hit the top-level handler or not.
Except that there are some times when you probably could: The target handler is (dynamically) known and doesn't raise. If the language doesn't support the 'cause' exception feature, you can allow a raise as long as the trace in the caught exception is never read and doesn't escape. Even if the trace does escape by one of these means, there is a property that you can infer over the handler stack that describes for which raise statements the stack frame might need to be filled. Unfortunately, maintaining that kind of stack makes setting up a try block more expensive than usual (I think it costs nothing on the CLR), but it's nowhere near as expensive as saguaro stacks or keeping the entire stack live. -- William Leslie Notice: Likely much of this email is, by the nature of copyright, covered under copyright law. You absolutely may reproduce any part of it in accordance with the copyright law of the nation you are reading this in. Any attempt to deny you those rights would be illegal without prior contractual agreement. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
