Re: Implement resumption model for exception handling?

wyrmok@plg.uwaterloo.ca (Russell Mok) writes:
> In "The Design and Evolution of C++" by Bjarne Stroustrup(1994), there
> is a chapter about exception. Stroustrup said the resumption model was
> rejected because it is inefficient and of little use.
>
> I DESPERATELY need to know why, in details. I read a paper on
> Exceptional C by Gehani and he mentioned the implementation requires
> cactus stack --- an implementation of multiple stack. He was brief and
> I don't really understand his reasoning.


I have not read the book by Gehani, but I do have some experience with
implementing a resumptive model of exception handling.


Many years ago, while in graduate school, I converted an application I
had written to use exceptions rather than the conventional status-code
checking method. The object was to show whether, and how much,
exception handling could improve efficiency. (The answer was, about
40% execution speedup and about a 40% code-space reduction. Your
mileage may vary, of course.)


The program was written in PL/I, and the version of PL/I I was using
was not a full-blown version so it didn't have the full range of PL/I
exception handling. So I implemented my own, requiring explicit calls
to support functions on block entry and exit and when registering a
handler. Exception handlers were themselves functions, nested inside
the block whose code they guarded. A handler could therefore access
all the local data of the guarded block. Once the exception handler
was finished, it could choose whether to just return, thereby resuming
execution from the original exception point, or perform a non-local
goto to a label within the guarded block, thereby terminating all the
intervening function calls like the termination model always does.


Note that I only allowed resumption from user-defined exceptions.
Program exceptions, such as a memory access error, required
termination of the block raising the exception.


In my project I was not comparing resumption vs. termination, so I
can't comment on the relative efficiencies. But I can say that my
resumption model required nothing more technologically advanced than
that required to support nested functions. Of course, that might
change if one changes the requirements substantially, but I also
cannot see why "cactus stacks" would be required.


One of the reasons that I liked my resumptive model is that it allowed
the handler to make the decision whether to resume. I have found many
situations over the years wherein a function detects a condition that,
while not preventing it from continuing, might indicate a problem that
the caller should know about. A resumptive model would allow such a
function to raise an exception that says "here is a condition that
could indicate a problem -- what do you want me to do?". The handler,
who (presumably) knows more context of why this function was called,
can then say "that's okay, go ahead as best you can" or it can say
"Ack! Bail out!"


One can implement a resumptive model with something akin to callbacks;
in fact, in a resumptive model an exception handler *is* a callback.
However, this means you now have two different models for exception
handling, and you have no language support for the resumptive model.
Most importantly, if you are working in a language that does not
support nested functions, your callback (handler) cannot access the
local state of the block it is guarding, making it much harder for the
callback to function appropriately.


--
Bill Leonard
Harris Computer Systems Corporation
2101 W. Cypress Creek Road
Fort Lauderdale, FL 33309
Bill.Leonard@mail.hcsc.com
--

Return to the comp.compilers page.
Search the comp.compilers archives again.