Boost logo

Boost :

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:

 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:
(Exceptions and Debugging, Jack Reeves)
(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.


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