Boost logo

Boost :

From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2003-07-18 07:10:19

jhopkin_at_[hidden] wrote:
> I agree that logic errors should be caught by assertions.
> The problem with throwing from logic errors is that when a logic error
> occurs, all bets are off.


> For example, if memory allocation fails, stack unwinding is the right thing
> to do, because it's clear what the code was intended to do and what part of
> that has failed.

Not always. <Forward-Inline> [...groups?]

-------- Original Message --------
Date: Thu, 10 Jul 2003 14:49:33 +0200
Newsgroups: comp.lang.c++.moderated
Subject: Re: strings in exceptions?
References: ... <uisqdt5cc.fsf_at_[hidden]>

David Abrahams wrote:
> Alexander Terekhov <terekhov_at_[hidden]> writes:
> > James Kanze wrote:
> > [...]
> >> Programs that core dump or fail to release resources are unusable. If
> >> you have functions which may throw exceptions, and you fail to take
> >> this into account, your programs will core dump or fail to release
> >> resources.
> >>
> >> The concept is known as exception safety, and has been widely
> >> discussed here. And you'll have a hard time convincing me that a
> >> programmer has handled all of the subtle exception safety issues
> >> correctly, but has ignored the most basic one: catch the exception.
> >
> > including std::logic_error (and alike stuff)?
> Stuff which should never be thrown in the first place? If you don't
> mean for it to be caught, it shouldn't be an exception.

For any exception that you mean/want "to be caught", your client(s)
may *rightfully* refuse to do it. I thought that I've fully explained
it in the past (without my usual "hint-dropping")... and you even
sort of agreed:


(Subject: Re: __attribute__((cleanup(function)) versus try/finally)

>                   Allocation failed => pretend object never existed and
> handle it higher up the call stack.
> If the program fails because the client code does something unexpected, how
> can we know what was intended? In the lock example, should the program
> ideally then rewind to before the initial lock happened and say 'please try
> again'?. In general, that's impractical, even if it could be ascertained
> what action should be taken.
> The lock library should assert on logic errors (IMO), ....
It could also do something along the lines of:
(Subject: Re: OO design:  Is "errno" Exception?)
  template<typename T, typename cleanup>
  void thread_specific_ptr<T, cleanup>::set(T* p) 
        throw(std::bad_alloc) {
    int status = __tsd_setspecific(__key, p);
    if (status) throw_errno_exception(status);
  extern "C" int pthread_setspecific(pthread_key_t key, 
                                     const void * p) throw(std::bad_alloc) {
    try {
      // can throw "shall fail" stuff only (std::bad_alloc)
      key->set(const_cast<void *>(p));
      // "may fail" shall be caught in the std::unexpected() handler
      // for details... please click here: <>
    catch(...) {
      return __translate_exception_to_error_code();
    return 0;
But the problem is that C++'s "exceptional folks" (lead by Abrahams/
Sutters/...) won't fix ES/EH (won't mandate 2-phase EH) until me-poor 
writes and submits some mysterious "paper" (me-poor won't do it).
P.S. <Forward Inline> (sorry, no link yet)
-------- Original Message --------
Message-ID: <3F1660DD.7F61C5DE_at_[hidden]>
Date: Thu, 17 Jul 2003 10:39:57 +0200
Newsgroups: comp.lang.c++.moderated
Subject: Re: strings in exceptions?
References: ... <3F13AC49.6C671F86_at_[hidden]>
Daniel Spangenberg wrote:
> are absolutely bullshit? 
Absolutely. Naked abort() for plain assertions and 2-phase EH 
``is all what you need.''

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