Christopher M. Gurnee wrote:
>
> The standard says uncaught_exception should still return true in e's
> dtor.  Perhaps uncaught_exception's definition should have included an
> exception to the rule like "if a new try-block is entered during stack
> unwinding, returns false until that block is exited."  But then, what
> if the catch block didn't catch all exceptions?  Throwing some
> exceptions from e would still be unsafe.  How about something like
> "... is exited iff a catch block of the form catch(...) exists."  Or
> something more general like "... iff a catch block for every possible
> exception that could be thrown," taking exception specs of all called
> functions into account.  This is quickly becoming very complicated : )

What the language needs isn't something "cute" like
uncaught_exception(), but something that more directly expresses what
people really want in practice. What they want to know is if it is
possible to throw a particular exception without colliding with stack
unwinding in progress and calling terminate(). Since that question
cannot be answered without specifying the type of the exception, no
parameterless function like uncaught_exception() will ever suffice.

The simplest thing would be to define a conditional throw expression
like "throw_if_safe x" that doesn't throw if it isn't safe to throw. For
consistency, I'd suggest that x be evaluated even if it doesn't get
thrown (just as "throw x" evaluates x even if terminate() winds up being
called). If it doesn't throw, then execution continues normally, either
with the next statement, or the rest of the expression if it is embedded
in an expression using the comma-operator.

I wonder if it would be such a bad idea simply to redefine "throw" to do
exactly that, rather than add a new keyword. Although terminate() is a
valid function, semantically any program that calls terminate() should
be considered broken, and no program should ever intentionally do
something that might call terminate(). Therefore, anything that makes
something else happen besides terminate() shouldn't break any "valid"
programs. Is falling off the end of a "throw" expression, where the
programmer didn't expect it, intrinsically worse than calling
terminate()?

I'm only suggesting that "throw x" not throw if the exception would
collide with stack unwinding in progress and call terminate(). I suspect
that the current behavior should be retained if a throw would result in
calling unexpected() due to inability to find a matching handler.

--

Ciao,
Paul
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]