TITLE: bad_exception and unexpected

(Newsgroups: comp.lang.c++.moderated, 26 Nov 96)

FRIESEN: swf@elsegundoca.ncr.com (Stan Friesen)

>> > The cost should be a gain.  By marking the function as "does not throw",
>> > this allows many optimizations across the function call that would
>> > otherwise
>> > be forbidden. (This is because "throw()" assures that if the function
>> > does
>> > not exit it throws no exceptions - that is it ensures that there are no
>> > extra control flows from the call point).

LEONARD: bill@amber.ssd.csd.harris.com (Bill Leonard)

>> Is this really true?  My understanding was that bad_exception could still
>> be thrown in this case.

KANZE: kanze@gabi-soft.fr (J. Kanze)

>Since no one else has answered: I think that the committee has changed
>the standard so that this is really true.  No exception can escape from
>the function

CLAMAGE: clamage@taumet.Eng.Sun.COM (Steve Clamage)

That's right. If a function attempts to exit via a disallowed exception,
the function unexpected() is called. That function cannot return, but
may exit via an exception. You can supply your own version of unexpected()
via the set_unexpected() function. In particular, unexpected() is
allowed to throw some other exeception that might be allowed by the
original function. (How you arrange for that is up to you. The default
version just calls terminate().)

If unexpected() exits via an exception that is not allowed by the
original function, terminate() is called automatically. Thus, we are
assured that a function with an empty throw specification cannot
exit via an exception.

One method to allow more graceful failure: Add the standard exception
type "bad_exception" to the exception specification of any function
that has a specification. Define unexpected() to throw bad_exception.
You can then catch bad_exception where ever it is convenient, and
retain more control over what happens next.