Re: Exception Misconceptions
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: 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. (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.
--
James Kanze