Related articles |
---|
[3 earlier articles] |
Re: Implementation of C++ exceptions ? chase@Think.COM (1994-04-05) |
Re: Implementation of C++ exceptions ? schmidt@tango.ICS.UCI.EDU (Douglas C. Schmidt) (1994-04-06) |
Re: Implementation of C++ exceptions ? mmc@wagner.imada.ou.dk (1994-04-07) |
Implementation of C++ exceptions ? ssimmons@convex.com (1994-04-08) |
Re: Implementation of C++ exceptions ? davis@ilog.ilog.fr (1994-04-11) |
Re: Implementation of C++ exceptions ? chase@Think.COM (1994-04-11) |
Re: Implementation of C++ exceptions ? sean@PICARD.TAMU.EDU (1994-04-12) |
Newsgroups: | comp.compilers |
From: | sean@PICARD.TAMU.EDU (Sean Barrett) |
Keywords: | C++, performance, design, comment |
Organization: | Fraternity of Avian Deists |
References: | 94-04-019 94-04-071 |
Date: | Tue, 12 Apr 1994 07:01:52 GMT |
In article 94-04-071, David Chase <chase@Think.COM> wrote:
>This all gets much more entertaining when you are trying to debug code,
>because then it is not permitted to destroy the stack as you search for a
>handler.
If the goal of exception handling is performance so long as no exceptions
are thrown, and the "problem" of exception handling is to execute
deconstructors for automatic variables,
Then isn't it true that any reasonable solution for debugger call-stack
tracebacks (i.e. the ability in a debugger to look up the call-stack and
display the values of variables in other procedures) provides all the
mechanisms necessary for exception handling?
Or is there a deeper problem? I guess what I really mean is this: Yes,
the details of how to do this are somewhat interesting, especially insofar
as they are details for how to make the raising of an exception itself go
fast. But I don't think I've ever seen people making a big fuss about the
difficulty of determining the types of variables on the stack for
debuggers, yet I've seen a lot of discussion about the apparently similar
problem for C++ exceptions.
Sean Barrett
[I expect the practical difference is that in most cases the symbol
information to decode stack frames is kept in the debugger rather than in
the executable itself. There are a whole bunch of reasons why it's nice
to give the executable access to its symbols, most notably dynamic linking,
so this is just another one. -John]
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.