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

From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-08-19 11:30:57

From: "Alexander Terekhov" <terekhov_at_[hidden]>
>
> 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

Yes, exactly. I claim that ignoring error returns from "release" style
methods is a better response than throwing an exception and hoping for the
best.

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

In order to provide the nothrow guarantee, since "release" style methods are
often called from nothrow functions.

Whether you spell your try block as try {} or as "throw()" doesn't really
matter.

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

Executive summary: we are in violent agreement. Bugs should abort(). You are
saying that bugs that don't abort() should throw in order to hit your
throw() spec, and I say that bugs that don't abort should only throw when
the circumstances are right, but those are details.