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

From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-08-17 12:58:30

From: "Alexander Terekhov" <terekhov_at_[hidden]>
>
> Peter Dimov wrote:
> [...]
> > > That is "usually" done using things like "validation sentinel", etc.
> > > Now, I think that it is reasonable to assume that our fancy C++
wrapper
> > > would simply "translate" it to std::invalid_argument exception.
> >
> > Our badly designed fancy C++ wrapper, you mean. :-)
>
> I mean hypothetical mutex::unlock() function from hypothetical
> <thread> header.

Yes, I understand.

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.

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

> BTW, I hope that it will also have defined
> pthread_mutex_t* mutex::c_mutex() function... meant to provide
> support to some "C" code using "just" facilities defined in
> hypothetical <cthread> header -- basically adopted <pthread>. ;-)

And scoped_lock should be global and use unqualified calls to
pthread_mutex_[un]lock(pm_) so it can be used with any mutex, including
pthread_mutex_t. ;-)

> > > So,
> > > unless your "never throws" function has throw() ES, there is indeed a
> > > chance that "you'll get a nicely packaged std::invalid_argument out of
> > > a function that is specified to not throw", I believe.
> >
> > Yes, there is a (slim) chance to get that. ....
>
> It's time for my Butenhof's-quote-of-the-day, I guess. ;-)
[...]

>  (Which leaves a much smaller set of explicit "bugchecks" to catch a few
>  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>  really severe internal errors that "can't happen".)"
>  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Right. But nowhere does he say that the severe internal errors that can't
happen should throw exceptions when detected. Wouldn't an NDEBUG ASSERT()
that calls unexpected()/terminate()/assertion_failed()/boost_error() do the
trick?

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? When
the internal logic of the program has been compromised, exceptions are no
longer appropriate. You just terminate the subprocess and respawn, right?