Boost logo

Boost :

From: E. Gladyshev (egladysh_at_[hidden])
Date: 2003-11-04 14:52:40

--- David Abrahams <dave_at_[hidden]> wrote:
> If your system gives you cause to worry about catch(...), it's much
> simpler to use the destructors of automatic objects than to define
> such a complicated mechanism for recovery.

Of course you should worry about catch(...) on any real system.
Also our programs are most likely not correct.

Using destructors is a completely different approach to
exception handling. If it is safer in practice, then
we should talk about it. It'll have huge consequences
on how "industry-strength" libraries is supposed to
be written.

> > So the claim that "Interactions between templates and exceptions are
> > not well-understood." might after all be true in opposite to what
> > your article is suggesting.
> Just as the article suggests, these issues are exactly the same ones
> that arise with library functions which accept function pointers or
> (runtime) polymorphic objects. There's no particular mysterious
> interaction with templates.
> And this is my last post in this thread. I hope it helped,

Yes, this discussion is really helped. Thanks to all!

Here is my last point.

My concern is that boost is a very respectable
site and community, so most people will look at your article
that has the following code:

template <class X>
void print_random_sequence()
    std::vector<X> v(10); // A vector of 10 items
    try {
        // Provides only the basic guarantee
        v.insert( v.begin(), X() );
    catch(...) {} // ignore any exceptions above
    // print the vector's contents
    std::cout "(" << v.size() << ") ";
    std::copy( v.begin(), v.end(),
    std::ostream_iterator<X>( std::cout, " " ) );

and assume that it is safe to use this approach in their programs
and that they are covered from trouble. It is really really dangerous.

I suggest for you to at least elaborate in your article on some
of the issues that have been discussed in this thread.


Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard

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