David Abrahams wrote: > > Alexander Terekhov <[EMAIL PROTECTED]> writes: > > > Terje Slettebų wrote in message <[EMAIL PROTECTED]>: > > [...] > >> > why shouldn't std::exception use std::strings? > >> > >> See here (http://www.boost.org/more/error_handling.html). > > > > ".... > > 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 <http://groups.google.com/groups?selm=3D873ADF.DA0444B1%40web.de> <copy&paste> 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 operation 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 operation pthread_exc_privinst_e Unhandled privileged instruction fault exception pthread_exc_resaddr_e Unhandled reserved addressing fault exception pthread_exc_resoper_e Unhandled reserved operand fault exception 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 signal pthread_exc_subrng_e Unhandled subscript out of range exception pthread_exc_uninitexc_e Uninitialized exception raised pthread_exit_e Thread exiting using pthread_exit() pthread_stackovf_e Attempted stack overflow was detected </copy&paste> that basically use a synchronous-signal-to-exception "translation" ala: <http://lists.boost.org/MailArchives/boost/msg36232.php> ".... 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]; .... [1] http://tru64unix.compaq.com/docs/base_doc/DOCUMENTATION/V51A_HTML/ARH9MBTE/VNTPRCSS.HTM#exc-sig-hand-coexistence ...." Well, it is true that there's no standard that would *require* them to be "named" C++ exceptions: <http://google.com/groups?selm=5Gml8.1103%24fL6.23421%40news.cpqcorp.net> ".... 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: <http://lists.boost.org/MailArchives/boost/msg34151.php> ".... 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 <http://.google.com/groups?selm=3DF7647E.C84435BC%40web.de> 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? ;-) regards, alexander. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
