🚀 go-pugleaf

Dick Menninger wrote:

>  [example omitted: destroying an auto array of objects]

>  Although the wisdom of continuing the backward destruction
>  of the array may be quite suspect, it seems that 15.2 of DWP
>  gives compilers no choice but to do that.

DWP requires all auto objects' dtors be called before they
go out of scope.  This seems very reasonable to me.  The
exception handling mechanism does not provide any means for
resuming execution after the throw point, hence any cleanup
operation that needs to be carried out before exiting the
given block has to be called before the exception is handled.

IMHO, this should include both further elements in an auto
array and base class dtors.

>                                            The danger seems
>  to be an inherent part of requiring exception handling
>  (including the destructor processing while unwinding) to be
>  exception-free.

AFAIK, destructor processing is not required to be exception
free.  Exception handling is a way to communicate failures
from dtors.  A typical example is reporting about system
errors when closing a file, and File::Close() is being
invoked from File::~File(), as it should.

>                  Part of the problem here is that there can be
>  an environmental thing for class T (or that particular array)
>  that puts destruction of the other instances into the same
>  exception case.

That is the big problem.  In some circumstances, when an
exception has already been thrown, it is better to avoid throwing
more.  It is a special case.

>                  If that is the case, the destructor for the
>  class has to do the initial catch and put the class into
>  a special state before rethrowing it.

But, the dtor can also be invoked in other critical
circumstances.  E.g.  during stack unwinding as a
consequence of an exception thrown from a different piece of
code.  Then the problem is not local to a class:  it is the
whole thread that should be put into a special state.  When
in such a state, the File::~File() function of the example
above should call File::Abort() instead of File::Close().

The problem is to know that an exception has been thrown.
Currently the language does not provide this feature and
dtors act blindly.  This is clearly a language
inconsistency:  the same arguments used pro exception in the
ARM are still valid for exceptions in destructors.  (Other
special functions are also involved, e.g.  ctors of
exception objects.)  I hope this problem will be solved
before the standardization process completes.

Bye
Alessandro Vesely
(mc6192@mclink.it)
---
[ 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. ]