TITLE: exception specifics, ARM vs the standard

(Newsgroups: comp.std.c++, 28 Oct 98)

???:

>> Can anyone summarize the difference, if any, between
>> exception handling as specified in the ARM and exception
>> handling as specified in the standard?


DEROCCO: "Paul D. DeRocco" <pderocco@ix.netcom.com>

> They added the uncaught_exception() function, which tells (not very
> usefully) whether or not there is an exception in the process of being
> thrown. They added function-try-blocks, which I've yet to find a use
> for. Those are the only differences I can think of off-hand.


CLAMAGE: stephen.clamage@sun.com (Steve Clamage)

The uncaught_exception function was added at the request of
people who really wanted to be able to throw exceptions
from destructors. (Why? I don't know.)

It isn't safe to throw an exception from a dtor unless you
know that you aren't currently unwinding the stack due to
another exception. The function allows you to find out
whether throwing the exception is safe.

My question is why it would be a good design to throw the
exception only sometimes, and if you can sometimes get along
without throwing it, why not always get along without
throwing it? Maybe that's what Paul meant by "not very useful".

The function-try-block is useful only for constructors.  If the
constructor for a member or base of a class C exits via an
exception, there was previously no way for the C constructor to
find out about it or intercept the exception. The function-try-
block can catch any exception thrown by the constructor of a
base or member.

The function-try-block was extended to all functions because
there didn't seem to be any reason not to. There also isn't
any use for it with non-constructors. For example, the following
two function versions are entirely equivalent:

#1
	int f() try
	{
	    ... function body
	}
	catch (...)
	{ ... }

#2
	int f()
	{
	    try {
	        ... function body
	    }
	    catch(...)
	    { ... }
	}