🚀 go-pugleaf

In article 95Dec4181558@shadow.cs.columbia.edu, fenster@cs.columbia.edu (Sam Fenster) writes:
> 
> The text from the DWP, as quoted by David Chase below, is actually completely
> unclear as to whether an exception thrown during processing of a prior
> exception causes program termination.

> >   "In the following situations, exception handling must be abandoned...
> >    ...
> >    -- when an attempt by the implementation to destroy an object during
> >       stack unwinding [1] exits [2] using an exception"

> > [1] Stack unwinding is defined to be the destruction of objects constructed
> > on the path from a try block to the throw-expression.

> > [2] "exits" is the crucial word -- a destructor which throws an exception
> > but does not propagate it to the destructor's caller, is not using the
> > exception to exit.


> The part of this text that makes it incomprehensible is the undefined
> terminology, "when an *attempt* exits..."  What is an "attempt"?  Do they
> mean:
> - "when any *function* exits using an exception"?
> - "when *any* *block* of code is exited by means of a `throw' statement"?
> - "when the *destructor* of an object that was on the stack when the prior
>   exception was thrown exits with an exception"?

I thought this was actually clearly worded.

  the stack is unwinding because an exception was thrown.

  because the stack is unwinding, objects are being destroyed.

  the destructor for one of these auto objects throws an exception and does
  not catch it -- that is, it exits (the bias of the author shows here, in
  that the destructor was merely "attempted", but I can live with this.)

Thus, it is your third choice.  A function call within a destructor is not
an attempt, nor is a block of code.  It is the running of the destructor that
is "attempted" (and in the mind of the author, fails, if an exception is
thrown).  Except, of course, that "during stack unwinding" is ambiguous.
For example:

class A {
public:
  ~A() { throw (17); }
...
};

class B {
public:
  ~B() {  try {
            { A a; } // destruction of "a" throws "int".
          } catch (...) { // which should be caught here.
          }
       }
}

void foo() {
   B b;
   throw ("cat"); // Exceptional exit, so that we will "unwind".
}

"During" could be read to mean that only b's destructor is subject to the
exceptional-exit == termination rule, or that a's destructor (which happens
to be invoked while the stack is being unwound, but not because an exception
was thrown through the frame in which "a" was allocated) is also subject
to this rule.

So actually, yes, it is confusing, but in a different way (IMO, of course).

I would prefer to say:

  -- when a destructor invoked as a direct consequence of stack unwinding
     exits by throwing an exception.

Except that, of course, I think that destructors should always be allowed to
throw exceptions, and if it occurs in the course of stack unwinding, then the
destructor's exception replaces the one which caused the destructor to be run,
just as if you said

  try {
   ...
  } catch (...) {
    ...
    throw (some_new_exception);
  }

and we would avoid this entire mess.

speaking for myself,

David Chase


[ 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. ]