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

From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2002-08-19 09:14:55

Peter Dimov wrote:
[...]
> As I already said, mutex::unlock() ("release"-type method) should not use
> exceptions to report errors (error code returns are fine.) mutex::lock()
> ("acquire"-type) should.     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

No, sorry. If error code returns are "fine", I'd really prefer 
exceptions. Apart from the rather nice side effect of avoiding 
silly checking in the main path, you just can't ignore them 
(unless you code those awful catch(...) things WITHOUT ES 
protection [limiting the set of eat/ignore exceptions]; also 
awful standard-required-unwinding-on-ES-violations aside ;-) ).

> There is little, if anything, that the user can do if mutex::unlock fails;
> it's either ignore (log) and continue, or terminate. An exception isn't
> appropriate; what would the high level handler do with it? 

You ask me? I have NO idea. But other people seem to kinda like 
the idea of spinning-for-a-while and trying to unwind their stuff; 
catching everything in main() or even in some d-tors with some 
silly catch(...) "handlers". 

In my view, there should be NO difference whatsoever between 
"no-handler-found" and hitting some exception propagation barrier 
[ES, d-tor that is unwound itself, etc.] -- that everything should 
result in calling unexpected() AT THROW POINT (no stack unwinding; 
two phase processing).

> The mutex is
> either locked (bad thing, must terminate, continue "business as usual" is
> wrong) or it's unlocked (postcondition met, can continue safely.)
> 
> If mutex::unlock does throw exceptions, everyone must wrap their unlocks in
> a try block.

Why? "everyone" (and his dog) simply shall NOT catch things s/he 
can't recover from, and catch/rethrow is usually just yet another 
awful "feature".  Throwing an exception on, for example, mandatory 
[EPERM] errors using ERRORCHECK mutexes would be OK, in my view 
(well, abort() right inside lock/unlock would be even better ;-) ).

[...]
> Really, it seems to me that you are trying to use throw() and exceptions as
> an assertion mechanism. Why? Can't you just use an assertion mechanism? 

I personally CAN. But a few corner cases aside, others seem NOT 
to be able to cope with calls to abort() -- explicit "bugchecks".

> When
> the internal logic of the program has been compromised, exceptions are no
> longer appropriate. You just terminate the subprocess and respawn, right?

Right. Re-start in-place preserving the state recorded at the last 
check point and eventually getting rid of "bad input" and go on to 
do something useful that appears "to work", or even fail-over [aka
"application move"] to another system in the {optionally 
geographically dispersed} parallel sysplex (cluster). ;-) ;-)

regards,
alexander.