Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!cica!ctrsol!uakari.primate.wisc.edu!indri!polyslo!ttwang
From: ttwang@polyslo.CalPoly.EDU (Thomas Wang)
Newsgroups: comp.lang.c++
Subject: Re: Handling trouble in C++
Keywords: exception error
Message-ID: <14013@polyslo.CalPoly.EDU>
Date: 28 Aug 89 20:03:25 GMT
References: <13789@polyslo.CalPoly.EDU> <13354@well.UUCP>
Reply-To: ttwang@polyslo.CalPoly.EDU (Thomas Wang)
Distribution: usa
Organization: Cal Poly State University -- San Luis Obispo
Lines: 66

nagle@well.UUCP (John Nagle) writes:
>In article <13789@polyslo.CalPoly.EDU> ttwang@polyslo.CalPoly.EDU (Thomas Wang) writes:
>>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.

>      No good.  What if failure is detected within a declaration, and
>only some of the objects associated with that block have been created
>at that point? The "local failure handling label" concept can't handle 
>this, lacking information about exactly which constructors have been properly
>instantiated.  

This is easily handled.  If there is only one local failure handler, you
can have a local variable that tells the location of the error.

a::a()
{
  int location = 0;
  do_something();
  location = 1;
  do_something2();
  location = 2;
....
}

Beside, if the language can implement one local failure handler, why can't
it have multiple local failure handlers?  This would solve the problem
nicely.

>      An even worse case comes when a constructor of a base class fails
>while construction of a derived class is underway.  Imagine instantiating
>"menu" and having "window" fail at a lower level because too many
>windows are open.

This is not a problem either.  The failure will be passed upward toward
the main() function, until the program is cleanly aborted.  The failure
from 'window' is passed to 'menu' after 'window' cleans up its structure.
The 'menu' then handles the failure, cleans up its structure, and pass
the failure upward...

>      When thinking about how to do this, it's worth remembering the
>design criterion for the exception handling mechanism in Ada that
>the overhead for the case in which no exceptions occur must be 
>minimized, even if this makes exception handling slow.

The destructor of C++ presents big problems to the implementors of
exception handling.  When a failure occurred, all the destructors for
local variables must be called up to the point where we have a failure
handler available.  We have two choices:  We can let destructors to be
handled locally, and check failure after every function call.  We can
also implement a local variable registry to handle the calling of destructors
in a global fashion.  I suspect the overhead for checking failure after
every function call is actualy smaller.

The paper "Exception Handling Without Language Extensions" in the 1988
Usenix C++ Conference describes a local variable registry implementation
outside the language itself.  So this method is at least known in the
computing world.

>				John Nagle

 -Thomas Wang (Ah so desu ka!)

                                                     ttwang@polyslo.calpoly.edu