[boost] Re: Attempting resolution of Threads & Exceptions Issue

From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2002-08-20 11:28:32

Peter Dimov wrote:
> 
> From: "Alexander Terekhov" <terekhov_at_[hidden]>
> >
> > Peter Dimov wrote:
> > >
> > > Alexander Terekhov <terekhov_at_[hidden]> wrote in message
> news:<3D613D44.9B67916_at_[hidden]>...
> > > > Peter Dimov wrote:
> > > > [...]
> > > > > What is brain dead, the concept or the implementation?
> > > >
> > > > The concept. I, personally, really don't like the idea of propagating
> > > > std::logic_error (and alike beasts) across threads on join -- ideally,
> > > > I want it to kill the process at throw point, unless someone really
> > > > wants to pretend that s/he can "recover" from it and catch it for that
> > > > or some other (most likely silly) reason;
> > >
> > > You can put an exception specification that prohibits std::logic_error
> > > on the threadproc (and hope that it doesn't unwind ;-) .)
> >                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >
> > Peter, I'm going to IGNORE your wink. ;-) That's rather serious
> > issue/design flaw in the current C++ language, I believe strongly.
> 
> It is, if you insist that throwing an exception is the right thing to do
> when you detect a programming error.
> 
> It's not, if you don't.

Yeah, the only problem is that it's not "that simple", I'm afraid.
(imagine that some find()-like function using something like get() 
below in some similar way... WOULD cause get() to "unexpectedly" 
throw -- due to something silly done prior to calling get() inside 
the if/loop (after size() check) or something else... perhaps another 
thread corrupting shared data, whatever... Y'know: errors that "can't 
happen" and that manifest themselves via unexpected throws; and NOT 
necessarily throwing std::logic_error-like things or generating 
SEH/"hardware exceptions").

http://www.bleading-edge.com/Publications/C++Report/v9607/Column2.rtf
http://www.bleading-edge.com/Publications/C++Report/v9607/Column2.htm
(Guidelines for Using Exception Specfications, Jack Reeves)

<quote>

Consider the following example (only slightly contrived).

X get(int i) throw(out_of_range);

int find(X& x) throw()
{

  for (int i = 0; i < size(); ++i) {

    if (x == get(i)) return i;

  }

  return -1;

}

Here, function find() calls a function, get(), which states that it 
can throw an exception. Function find() however, has an exception 
specification that states that it will not throw any exceptions. If 
exception specifications were checked a compile time, then function 
find() would generate an error message on the line that calls get(). 
Nevertheless, this programmer has carefully written find() to include 
a test (i < size()) that will avoid the condition which would cause 
get() to throw an exception. In C++ (as in C) the assumption is that 
the programmer knows what he is doing. C++ programmers expect this 
to compile without even a warning. Certainly, I would not want to 
write code like this int find(X& x) throw()

try {

  for (int i = 0; i < size(); ++i) {

    if (x == get(i)) return i;

  }

  return -1;

}
catch (out_of_range) {

  return -1;

}

</quote>

regards,
alexander.

P.S. http://groups.google.com/groups?selm=c29b5e33.0202110310.413c19cb%40posting.google.com
     ("Subject: Re: Java-like exception specifications", #pragma unexpected_exception)