Boost logo

Boost :

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?


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk