🚀 go-pugleaf

In article <49tuq4$238@wcap.centerline.com> chase@centerline.com writes:

> The first problem I have is that my reading of this is that a
> destructor invoked because a block is exited non-exceptionally, can
> throw an exception WITHOUT causing terminate to be called.  But, if
> that destructor is called be the block is exited exceptionally,
> terminate is not called.  This seems, to me, to be a weird
> inconsistency.  (How could someone writing a destructor know the cause
> of their call?) Is this just an oversight?

It is not an oversight.  One reason for the distinction is that otherwise
it would have been necessary to draw a clearly visible dividing line between
when end-of-block destruction of objects starts and when it has not started
yet.  But other things, such as compiler-generated temporaries, are destroyed
during a block before any kind of stack unwinding starts, and their destructors
could throw exceptions too.

So instead we take the view that there's this system-defined thing called
stack unwinding that happens only as part of exception handling.  Exiting
from user code by an exception is OK, even if that user code is in the process
of destroying local objects.  Exiting from stack unwinding by an exception
is not OK.

> The minor gripe is that I think that the choice should be the second
> one -- I see no reason why destructors should not be permitted to throw
> exceptions in the way that I describe above.  There is some additional
> hair required to ensure that the "lost" exception is properly destructed,
> but that hair had to be there anyway to deal with throws/re-throws from
> handlers.

You may be right.  The reason the prohibition is there is that while unwinding
is in progress there is an object that must eventually be cleaned up, namely
the object that was thrown.  What if that object's destructor throws an exception?
More generally, we opted for the draconian treatment because liberalizing it
is easier than making something stricter that was inadvertently too liberal.
I was hoping that someone would come forward with a reason to change the
present treatment, but no one ever did.
-- 
				--Andrew Koenig
				  ark@research.att.com


---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]