Re: [c++-pthreads] Re: thread-safety definition
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [c++-pthreads] Re: thread-safety definition
- To: Dave Butenhof <David.Butenhof@xxxxxx>
- Subject: Re: [c++-pthreads] Re: thread-safety definition
- From: Matt Austern <austern@xxxxxxxxx>
- Date: Mon, 12 Jan 2004 10:29:00 -0800
On Jan 12, 2004, at 5:41 AM, Dave Butenhof wrote:
I think I disagree, at least philsophically, with the characterization
of the model as "fragile". But I think I also understand what you
mean; and the problem isn't with the model, but rather with the effect
of that model on existing code that all-too-casually and agressively
eats exceptions it doesn't understand. I think there are vanishingly
few circumstances where a blind catch(...) without an unconditional
re-throw should be considered "legitimate". If you don't completely
understand what an exception means, you cannot claim to have
completely recovered, and therefore cannot reasonably finalize
propagation. (And when you catch anonymously, you can't possibly
understand what they mean since you can't even identify them.) On the
other hand, regardless of whether the semantics are meaningful or
reasonable, the syntax is legal and apparently (unfortunately) in
common use, so I can't dispute that you need to consider that.
One legitimate use for that pattern is in mixed-language programming,
when you write a little adapter to turn the error reporting mechanism
used by the C++ part into an error reporting mechanism that the C part
can understand. I think that's reasonable for most of the things
exceptions are used for. It isn't reasonable for thread cancellation,
because C needs to know about thread cancellation too. (Maybe this
means that thread cancellation isn't quite "error reporting".)
It looks to me like most of the recent discussion has come back to
catch(...). I wonder if that's really the fundamental problem we have
to solve?
--Matt