Re: thread-safety definition

[David Abrahams <dave@xxxxxxxxxxxxxxxxxxxx>]

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.

The only way handling an exception with catch(...) can be harmful
(other than to debugging; but that's a different issue) is if the
throwing code *requires* that the catching code take some special
condition-specific cleanup actions in order to ensure program
correctness.  I don't think I've seen such an arrangement under any
error-handling system, though it wouldn't surprise me if an example
existed somewhere. IMO it's much more reasonable to say "don't do
that" with exceptions than to tell people not to use catch(...).  It's
easy enough to force that special cleanup action in the exception
object's destructor a la JasonMerrillCancellation in the rare case
where something of the sort might be needed.

But this is all OT for the threads discussion, innit?
-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com