🚀 go-pugleaf

> > someone wrote :
> > > > I cannot see any logical argument why one of
> > > >       a) unwinding the whole stack or
> > > >       b) just terminating without unwinding it
> > > > should be prefered by this principle.

> >Unless the draft standard specifies that a call to
> >"terminate" may ONLY be used for debugging purposes, it is
> >both legal and likely for it to do something else, such as
> >printing a message before exiting.

Etay Bogner <ebogner@ird.scitex.com> writes:
> I really can't see what's the connection between your message and example to the issue here.
> The original question ( I believe ) was why it is un-specified in the standard whether the stack 
> is unwind when terminate is called.

> I gave a simple answer to this Q.

You gave a simple reply.  It was not an answer, at least not
to me.  Any ambiguity in the standard must be well-justified,
and "you can dump core on Unix, but not on PC's" is not an
answer.

> You can write whatever terminate/unexpected function you like.

No, you cannot.  The draft specifies (last time I looked) that
it is not allowed to "return" in the normal fashion.  However,
it is possible to write a terminate (I can imagine doing such)
that would depend on whether or not the stack had unwound
(whether destructors had been run).

> It's a simple fact that if the standard commitee enforced "a", some
> people wouldn't be happy since they couldn't debug their programs as
> they used to.

Then perhaps the standard committee should enforce "b".  They
should enforce *something*.  If there are reasons to call a
terminate-like function both before and after the stack has
unwound, then perhaps they should specify one for before, and
another for after.  I can think of one excellent reason to call
terminate BEFORE the stack has unwound, namely that we've
already got the ability to detect uncaught exceptions AFTER the
stack has been mostly unwound, by writing:

  main() { try { /* ... */ } catch (...) { my_terminate(); } }

Note that this does not catch problems in static constructors.

> The sample code you wrote just indicate ( detect ) whether or not the
> detructors are called, which is NOT that useful ...

It's an example.  You would prefer, perhaps, that I post the
source to a debugging interpreter, or a window manager?  The
point is that this procedure CAN detect this situation.  So can
other, more complicated, and more useful replacements for
terminate.  The example I posted is also very useful in that it
could be incorporated into a language verification suite, IF a
choice were made.

> And all this doesn't say that terminate "may ONLY be used for debugging
> purposes". A programmer can choose to exit that way from his program,
> if he likes that.

Exactly my point.  If a programmer chooses to exit from his
program in this way, does this have portable behavior? 
(currently, no) If not, why not?  Ambiguity in standards is bad,
and should not exist unless there is some other benefit for the
programmer derived from leaving the ambiguity in.  What benefit
does the programmer derive from this ambiguity?

speaking for myself,

David Chase