Boost logo

Boost :

From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2003-06-05 05:13:43

David Abrahams wrote:
> Alexander Terekhov <terekhov_at_[hidden]> writes:
> > Terje Slettebø wrote in message <Hi7Da.9988$KF1.142210_at_amstwist00>:
> > [...]
> >> > why shouldn't std::exception use std::strings?
> >>
> >> See here (
> >
> > "....
> > Unfortunately, operating systems other than Windows also wind non-C++
> > "exceptions" (such as thread cancellation) into the C++ EH machinery
> > ...."
> >
> > There's no such thing as 'non-C++ "exceptions"'.
> Exceptions that have no C++ type associated with them and exceptions
> which are thrown by the system under conditions which the standard
> does not allow for (e.g. asynchronous exceptions without the presence
> of user-invoked undefined behavior) are what I mean by "non-C++
> exceptions".

First off, I was talking about *synchronous* stuff -- things like


 pthread_exc_aritherr_e Unhandled floating-point exception signal
                         ("arithmetic error")

 pthread_exc_decovf_e Unhandled decimal overflow exception

 pthread_exc_excpu_e "cpu-time limit exceeded"

 pthread_exc_exfilsiz_e "File size limit exceeded"

 pthread_exc_exquota_e Operation failed due to insufficient quota

 pthread_exc_fltdiv_e Unhandled floating-point/decimal divide by
                         zero exception

 pthread_exc_fltovf_e Unhandled floating-point overflow exception

 pthread_exc_fltund_e Unhandled floating-point underflow exception

 pthread_exc_illaddr_e Data or object could not be referenced

 pthread_exc_illinstr_e Unhandled illegal instruction signal
                         ("illegal instruction")

 pthread_exc_insfmem_e Insufficient virtual memory for requested

 pthread_exc_intdiv_e Unhandled integer divide by zero exception

 pthread_exc_intovf_e Unhandled integer overflow exception

 pthread_exc_noexcmem_e Out of memory while processing an exception

 pthread_exc_nopriv_e Insufficient privilege for requested

 pthread_exc_privinst_e Unhandled privileged instruction fault

 pthread_exc_resaddr_e Unhandled reserved addressing fault

 pthread_exc_resoper_e Unhandled reserved operand fault

 pthread_exc_SIGABRT_e Unhandled signal ABORT

 pthread_exc_SIGBUS_e Unhandled bus error signal

 pthread_exc_SIGEMT_e Unhandled EMT signal

 pthread_exc_SIGFPE_e Unhandled floating-point exception signal

 pthread_exc_SIGILL_e Unhandled illegal instruction signal

 pthread_exc_SIGIOT_e Unhandled IOT signal

 pthread_exc_SIGPIPE_e Unhandled broken pipe signal

 pthread_exc_SIGSEGV_e Unhandled segmentation violation signal

 pthread_exc_SIGSYS_e Unhandled bad system call signal

 pthread_exc_SIGTRAP_e Unhandled trace or breakpoint trap

 pthread_exc_subrng_e Unhandled subscript out of range

 pthread_exc_uninitexc_e Uninitialized exception raised

 pthread_exit_e Thread exiting using pthread_exit()

 pthread_stackovf_e Attempted stack overflow was detected


that basically use a synchronous-signal-to-exception "translation"
ala: <>

 just like any other SEH/C-exception beast, I believe [but there
 should be a way to control "hardware"/synchronous-signals stuff
 ala exc_raise_signal_exception()[1];

Well, it is true that there's no standard that would *require*
them to be "named" C++ exceptions:

 At one point, we tried to work with the C++ team to develop a way
 for C++ programmers to catch() cancel and exit by name -- for
 various reasons, that never shipped.

However, with respect to cathing, they're basically the same as
rather funny Sutter's "DieDieDie" *native C++* beasts:

 void DieDieDie() // unwind back to the last "catch(...)"
   class LocalClass {};
   throw LocalClass();

Now, speaking of asynchronous exceptions (async-cancel-safety)...
currently, I have really nothing to add to what I wrote previously
(see <>
if you want).

> > Brain-damaged forced unwinding aside for a moment, an implementation
> > provided exceptions for thread exit, cancelation... AND
> > synchronous-signals-translated- to-exceptions ARE "normal" C++
> > exceptions.
> That really depends on the implementation.
> > And, BTW, it's quite reasonable to expect that they're all derived
> > from std::exception...
> Except that they're not even always C++ types (c.f. Microsoft).
> > "....
> > if every exception were derived from std::exception and everyone
> > substituted catch(std::exception&) for catch(...), the world would
> > be a better place.
> > ...."
> >
> > The world WILL be a better place when people finally realize that
> > C++ DOES need a mandatory 2-phase exception handling and that the
> > current C++ standard is seriously broken with respect to exceptions
> > specs (plus a few other "less important" EH-related things). It
> > desperately needs some fixing.
> So quit complaining ineffectively and submit a DR with suggested
> wording changes. [That is a non-boost issue, BTW. If you want to
> discuss it, you should take it elsewhere]

I've just forwarded to you my reply to a message that I was asked to
"NOT POST to wide-distribution email distributions (e.g., Boost,
Austin Group) or newsgroups". Back then, I wrote the following to a
person who contacted me:

 Well, could you please [at the October 2002 meeting] sensor a bit
 "the situation"/climate with respect to general desire/ability to
 change anything at all in the C++ exception handling. I mean: would
 people be ready/interested to seriously talk/thing about:

 bool expected_exception<T>();

He hasn't yet replied... well, perhaps YOU could shed some light? ;-)


Boost list run by bdawes at, gregod at, cpdaniel at, john at