Re: Exception Misconceptions
On Dec 11, 8:57 am, "dragan" <spambus...@prodigy.net> wrote:
James Kanze wrote:
On Dec 10, 6:50 am, "dragan" <spambus...@prodigy.net> wrote:
James Kanze wrote:
On Dec 9, 10:33 am, "dragan" <spambus...@prodigy.net> wrote:
I got the idea and material for this thread from the
"high-class" ( ;) ) ng clc++m. Please add any commonly
held/observed misconceptions about C++ exceptions or
exceptions in general. Both mechanism and condition
misconceptions are fine. I'll start...
"Exceptions invoke all destructors while unwinding the
stack."
I think that is probably incorrect, though I'm not a
compiler writer so can't say with high certainty that it
is a misconception. I hypothesize that the compiler
introduces some kind of "jumps to the closing brace" and
lets the normal destruction of stack class objects
happen. An explicit mechanism that is part of the
exception machinery that calls destructors? I don't think
so.
You hypothesize wrong. The usual implementation (except
maybe for Microsoft) is to generate tables mapping code
addresses to clean up functions; the exception propagation
code (in the library) finds the frame pointer from the
stack, uses the table to find the clean up code, and calls
it, for each stack frame. I think some earlier compilers
generated additional code in the constructor to "register"
the class, but the table method is generally considered
preferable, as it has almost no runtime overhead until the
exception is thrown.
What is the mechanism and how does it work in the no-throw
function case?
The mechanism is more or less what I described:
Are you saying that there then is NOT a distinct mechanism for
exceptions that does unwinding?
What do you mean by "distinct mechanism"? Every compiler (or
sometimes the platform ABI) defines a mechanism to be used.
What has to happen is specified by the standard; how the
compiler achieves this is unspecified.
for each distinct set of objects to clean up, the compiler
generates a clean-up function, and puts its address in a
table along with the code addresses for which this function
is valid.
I hypothesized that there was no mechanism, separate from the
case where there are no exception elements in the code, (read
NOT TWO mechanisms) to do unwind explicitly for exceptions and
tied explicitly ('distinctly' may be a better word) to the
exception machinery. Is that hypothesis right or wrong?
$ don't understand what you're hypothesising. The compiler has
to generate something to handle exceptions in order to be
conform. The standard says what the observable behavior must
be, not what the compiler does to achieve that.
(This code
can be destructors or catch blocks. In the latter case, the
compiler also provides information concerning the types for
which the try block is valid.) When an exception is thrown, the
compiler calls code which walks back up the stack. For each
return address it finds, it looks up in the table what it has to
do, and does it.
Typically, the case of nothrow is treated by generating the same
code as if the function were wrapped in a try block, and
handling the error in a catch.
Other solutions are possible. Microsoft, for example, seems to
generate code which is executed in the case where the exception
isn't thrown, although I don't know what it's exact role is.
It sounds like I was right then.
Right about what? You said that you thought "Exceptions invoke
all destructors while unwinding the stack" was probably
incorrect---if you meant "all destructors of objects which cease
to be in scope", the statement is correct, and you're wrong.
You hypothesized that the compiler introduces some kind of
`jumps to the closing brace' and lets the normal destruction of
stack class objects happen": this hypothesis is wrong, at least
for the compilers I know. You also said "An explicit mechanism
that is part of the exception machinery that calls destructors?
I don't think so." I'm not sure what you mean by that, but the
compiler definitely does generate code which is specific to
exception handling, and it is that code which calls the
destructors.
--
James Kanze