From: Ben Tilly <[email protected]> Date: Fri, 19 Mar 2010 11:34:41 -0700
On Fri, Mar 19, 2010 at 11:07 AM, Conor Walsh <[email protected]> wrote: > I'm curious. > > Maybe I'm out of my depth, pun not intended, but I was under the > impression that thrown exceptions have to unwind the stack anyway. > Is there some way exceptions are usually implemented that doesn't > cost as much as unwinding the stack one level at a time? The issue is this. If you don't use exceptions then you have to have if checks on every return for exceptional conditions. Those checks are individually fast, but there are a lot of them . . . And, critically, those tests must run on *every* invocation, not just in an exceptional situation. If there are loops, of course, it's that much worse. > This is a fantastic discussion and I'm happy to see it here. It is surprisingly involved and detailed. I've been happy to read through it. Ben Ditto. ================ From: John Redford <[email protected]> Date: Fri, 19 Mar 2010 14:55:45 -0400 Also (relative to Ben Tilly's mail), it is possible to use techniques like maintaining a table of current handlers and using dynamic jumps in order to bypass uninteresting stack frames and hop directly to the "finally" code that calls destructors & such, and to the handler for the exception being raised. That is (IME) the usual implementation (it actually uses a linked list), which means that you pay the price at runtime only for frames that actually require "finally" handlers. Of course, if a given implementation presumes "Exceptions are always errors", it may walk the stack anyway and build up a whole data structure that describes where the exception took place. That would indeed be fairly slow to say the least . . . Better is a language design where the handler runs in the dynamic context of the exception, and gets to decide what to do, and how much information to capture. Like Perl 6. (Does this mean we're back on topic now? ;-) -- Bob Rogers http://www.rgrjr.com/ _______________________________________________ Boston-pm mailing list [email protected] http://mail.pm.org/mailman/listinfo/boston-pm
