Re: [3.3] Followup to C++ forced unwinding

[Mark Mitchell <mark at codesourcery dot com>]

On Wed, 2003-04-30 at 18:51, Ulrich Drepper wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Mark Mitchell wrote:
> 
> > You still haven't explained what might happen outside the catch-clause
> > that cannot happen inside the catch-clause or inside a destructor.
> 
> It is unspecified.  That's the whole point.


I know that POSIX doesn't endorse this particular behavior, and that
code that relies on it is non-portable -- but so is unwinding the
stack.  You could even reasonably argue that unwinding the stack is a
violation of the POSIX standard; it doesn't say that you do that.

You've said that falling off the end of a catch clause might cause all
kinds of bad things to happen, like process crashes.  I'm trying to find
out why.  And why that isn't a problem in destructors.

I'm not trying to find out why that could be true on some hypothetical
POSIX system; I want to find out why GNU/Linux, with the GNU C library,
cannot fall off the end of a catch-clause, but can safely execute code
in a destructor.

> > Whether that is supposed to happen or not depends on whether the user
> > wrote "throw;" in the catch-clause.  It's perfectly reasonable to fall
> > off the end of catch-clauses; that's one way of saying "try this
> > operation but keep going if it fails."
> 
> Then calling the code in catch() is wrong for cancellation.

You can't know that apriori.  

The C++ programming language does not give you the information you want;
it does not distinguish "catch" indicating "this is where important
resources are cleaned up" and "catch" indicating "I want to keep going
if something bad happens."  Sometimes "catch" indicates both of these
things, or one or the other depending on some condition.

Since the language doesn't tell you that, you have to trust the
programmer.  It's wrong to try to either skip the clean up or rethrow
from the end of the clean up; either will drastically change the
semantics of programs.

> > There's no way that we'll ever be able to run code inside a catch clause
> > other than "catch (...)"; the exception thrown is not of the right type,
> > so there's no way to bind the handler parameter.  Therefore, I think
> > that if we're going to unwind the stack, it makes sense to skip over
> > catch-clauses, other than "catch (...)" clauses.
> 
> This assumes that the cancellation "exception" is not derived from
> exception.  If this is the general concensus it's perfectly fine with me.

Or, rather, it assumes that it's not derived from any C++ type
whatsoever.

If we change that assumption later, that's OK; some programs that used
to abort will now handle the exception.

-- 
Mark Mitchell <mark@codesourcery.com>
CodeSourcery, LLC