Re: thread-safety definition

[David Abrahams <dave@xxxxxxxxxxxxxxxxxxxx>]

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?"

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

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

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com