[boost] Re: Exception handling... it's time to fix the http://www.boost.org/more/error_handling.html

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 (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.