Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wasatch!cs.utexas.edu!usc!polyslo!ttwang
From: ttwang@polyslo.CalPoly.EDU (Thomas Wang)
Newsgroups: comp.lang.c++
Subject: Re: Handling trouble in C++
Keywords: exception error
Message-ID: <13789@polyslo.CalPoly.EDU>
Date: 25 Aug 89 09:05:24 GMT
References: <13262@well.UUCP> <24F42DB0.D08@marob.masa.com>
Reply-To: ttwang@polyslo.CalPoly.EDU (Thomas Wang)
Distribution: usa
Organization: Cal Poly State University -- San Luis Obispo
Lines: 34

cowan@marob.masa.com (John Cowan) writes:

>This is part of the general C++ weakness in the area of signalling errors.
>I understand some smart cookies at Bell Labs are thinking about this, but
>so far without success, due to the very weak and non-portable handling of
>non-local jumps in the underlying C.

I would suggest to do a check on the failure variable after
every function call, and if a failure has occurred then goto the local
failure handling label.  There is always a local failure handling label,
even if the code at the label only calls some destructors, then returns
to the caller.

We cannot directly pop multiple stack frames, because the destructors will
not be called.  Therefore the only alternative is to pop one stack frame
at a time and to dutifully call the destructors.

In languages without destructors (e.g. Eiffel), we can directly pop multiple
stack frames.  Since C++ chooses the path of no garbage collection, there
will have to be some overhead for the failure handling mechanism.

We then have a choice to make.  Do we tell the function about the address
of the failure handler, or should we check for failure status after the
function call is completed.  It seems to me the second choice is better.

An important advantage of this scheme is that a C program calling C++
functions can use the failure handling mechanism.  The C program can just
test the failure variable after the C++ function call.  If the failure
variable is a register variable, the overhead should not be too great.

 -Thomas Wang ("I am, therefore I am."
                 - Akira               )

                                                     ttwang@polyslo.calpoly.edu