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

From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2002-08-17 10:17:53

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

BTW, some interesting thoughts on using exceptions to report rather 
funny things can be found here:

http://www.bleading-edge.com/Publications/C++Report/v9609/Column3.rtf
http://www.bleading-edge.com/Publications/C++Report/v9609/Column3.htm
(Exceptions and Debugging, Jack Reeves)

http://www.bleading-edge.com/Publications/C++Report/v9703/Column5.rtf
http://www.bleading-edge.com/Publications/C++Report/v9703/Column5.htm
(Reflections on Exceptions and the STL, Jack Reeves):

> > Yeah, I know,
> > folks who publish code like this
> >
> >     class scoped_lock
> >     {
> >     private:
> >
> >         pthread_mutex_t & m_;
> >
> >         scoped_lock(scoped_lock const &);
> >         scoped_lock & operator=(scoped_lock const &);
> >
> >     public:
> >
> >         scoped_lock(lightweight_mutex & m): m_(m.m_)
> >         {
> >             pthread_mutex_lock(&m_);
> >         }
> >
> >         ~scoped_lock()
> >         {
> >             pthread_mutex_unlock(&m_);
> >         }
> >     };
> >
> > [NOT coding any "old fashioned" checks for errors], will probably
> 
> Could you please elaborate on that? What, in your opinion, is not correct in
> lwm_pthreads.hpp? What are you suggestions?

"asserts" [I'd also add throw() ex.specs] are missing, I guess.

[...]
> In other words, you think that a function that is specified to not throw
> must immediately invoke unexpected() at the throw point?

Yep, unless it is something EXPECTED that is thrown -- it IS caught 
and fully "handled" inside throw() routine. Unwinding could only 
hurt, and will likely just destroy valuable "context" that would,
otherwise, help problem analysis, to begin with.

regards,
alexander.