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.