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

From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-08-17 10:38:48

From: "Alexander Terekhov" <terekhov_at_[hidden]>
>
> Peter Dimov wrote:
> [...]
> > > Yep, I DO assume that sometimes "functions don't work"... due to bugs,
> > > corrupted program state, whatever resulting in throwing somewhat funny
> > > exceptions along the lines of std::logic_error, std::invalid_argument,
> > > etc. as a product of some unexpected internal failures.
> >
> > What makes you think that you'll get a nicely packaged
std::invalid_argument
> > out of a function that is specified to not throw?
>
> Think of some C++ "wrapper" function for something along the lines
> of "pthread_mutex_unlock(&m_)" that you'd call from "never throws"
> ~scoped_lock() like function.

~scoped_lock _is_ the C++ wrapper function. In general, C++ "release" style
functions should not signal errors via exceptions; and if ~scoped_lock did
call a C++ function that is not specified not to throw, it would have a try
block to protect itself, or it would have a bug.

> Undefined behaviors aside,
> pthread_mutex_unlock is specified ("may fail if") to return EINVAL:
>
>
http://www.opengroup.org/onlinepubs/007904975/functions/pthread_mutex_unlock
.html
>
> "[EINVAL]
>  The value specified by mutex does not refer to an initialized mutex
object."
>
> 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. :-)

> 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. But I thought we are talking
about "resilient" (paranoid) programming, where you assume that nothrow
functions may throw, functions may not act as specified, and postconditions
might not hold. In this world, you must _not_ assume that the function will
fail to follow its spec in a way that is most convenient to you (i.e.
throwing a nicely packaged std::invalid_argument.)