Re: [c++-pthreads] Re: thread-safety definition

[Gabriel Dos Reis <gdr@xxxxxxxxxxxxxxxxxxxxxxxx>]

David Abrahams <dave@xxxxxxxxxxxxxxxxxxxx> writes:

| Gabriel Dos Reis <gdr@xxxxxxxxxxxxxxxxxxxxxxxx> writes:
| 
| > David Abrahams <dave@xxxxxxxxxxxxxxxxxxxx> writes:
| >
| > | Dave Butenhof <David.Butenhof@xxxxxx> writes:
| > | 
| > | >>The problems with catch(...) eating all exceptions are maybe not as
| > | >>bad as you think.  As a matter of fact, there are vanishingly few
| > | >>exceptions that demand special recovery actions that wouldn't work for
| > | >>all other exceptions.  Systems designed that way tend towards
| > | >>fragility.
| > | >>  
| > | >>
| > | > I see an immense difference between a pragmatic statement that "in
| > | > practice there seem to be few exceptions" and something on which
| > | > cross-platform, mixed-language, modular environment programmers can
| > | > depend as a law. C++ does not say that "all exceptions can be
| > | > finalized and recovered fully by performing these steps". To presume
| > | > they can is fragile.
| > | 
| > | It also doesn't say "no destructors will throw exceptions", but we
| > | generally rely on them not to, because it makes programs hard to
| > | write.  There are a whole host of things we leave up to good
| > | programming practice, most of which don't have to do with EH.
| >
| > Agreed, but we can't specify things like that.  If we assume some
| > working hypothesis to hold, then we have to make that assumption clear
| > in the specification.  I think that is the point Dave Butenhof was
| > making. 
| 
| I didn't think so, at all.  I hope Dave will clarify on his own,
| though, especially if I'm wrong.
| 
| AFAICT the discussion is about whether it makes sense to support
| programs which do catch(...) without rethrowing, and if so, how.
| Right now we're discussing a morality issue: "is it inherently evil to
| catch(...)  without rethrowing?"

I understood the scope of the discussion.

| My point is that one could just as well (and perhaps more justifiably)
| claim that it's evil to throw any exception that can't be dealt with
| via a catch(...) block that doesn't rethrow, where that block was
| designed to handle, say, bad_alloc.**

Well, let me rephrase what I was saying.

From language point of view, it is permitted to do catch(...) without
rethrowing. From practical point of view one may declare such style
either utterly nonsense or blessed.  Either way, that working
assumption should be stated clearly, .e.g.

   This POSIX binding specification assumes that a catch-all handler
   that does not rethrow belongs to hell.

or

   In this POSIX binding specification, a catch-all handler that does
   rethrow has a blessed behaviour. 

Such clear statement, from portability point of view, has different
impact than an unspoken assumption.

That is how I understood Dave Butenhof's statement.  But, you're right
that he might want to clarify on this own.

| (**) this isn't really about the exception objects, but about the
| conditions of program state they represent.

Yes, I understood that too.

-- Gaby