Boost logo

Boost :

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). ;-) ;-)


Boost list run by bdawes at, gregod at, cpdaniel at, john at