From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-08-17 07:44:11
From: "Alexander Terekhov" <TEREKHOV_at_[hidden]>
>
> Peter Dimov wrote:
> [...]
> > > > > Even if some throw() operation would suddenly throw?
> > > >
> > > > What language are you talking about here?
> > >
> > > Here, I'm talking about boostified(*) ``C++ language'' and boostified
> C++
> > > libraries full of "operation() // throw()", "operation() // never
> throws",
> >
> > These operations cannot "suddenly throw". If you assume that they can
> > "suddenly throw", you must assume that the rest of the documentation is
> > wrong, too. In other words, you must assume that the functions don't
> work.
>
> 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?
> 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?
> disagree and simply say to me: THAT'S UNDEFINED BEHAVIOR, STUPID.
Sorry, I completely lost the thread here. What is undefined behavior? How
does this relate to our discussion?
> > > and etc. "throw()" functions WITHOUT proper exception specifications.
> >
> > Define "proper" exception specifications. I've never seen one.
>
> Uhmm. Not sure what you mean. Well, to me, "proper" exception
> specifications would work like what we have currently, but would
> PROHIBIT unwinding on violations [get rid of silly catch(...)-
> in-function-try-block-"handler" semantics]; with unexpected()
> invoked at throw point. That would require TWO PHASE processing
> ["modern" stuff] and would add to the overhead associated with
> archaic setjmp/longjmp implementations, but who cares? ;-)
In other words, you think that a function that is specified to not throw
must immediately invoke unexpected() at the throw point?