Subject: Re: [boost] [exception]throw_exceptions concerns
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2009-01-02 17:16:15
On Fri, Jan 2, 2009 at 5:19 AM, Gennadiy Rozental
> 1. What does the first one means and should we worry?
You shouldn't worry, it means that you can't catch a bad_weak_ptr
exception as exception_detail::clone_impl<bad_weak_ptr>, which is by
> 2. Does the second means that std::exception is not copy constructible? If
> yes can we disable it inside the header?
I suppose you mean boost::exception, not std::exception.
Boost::exception is copy constructable but its copy constructor is
protected to prevent the user from accidentally slicing the exception
object using a catch(boost::exception e) instead of the correct
catch(boost::exception & e).
> a) Was it agreed that practically all Boost users are now exposed to the
> Boost.Exceptions library by default whether they are willing or not
There was rather lack of interest in discussion before this change in
throw_exception was implemented, but there was a later discussion
which lead to refactoring of the throw_exception hook.
"Exposed to" is technically correct, but that exposure is limited to
"boost/exception/exception.hpp", which does not include any headers
and was carefully designed for the purpose of the throw_exception
> b) throw_exception documentation is now incorrect and misleading, since it
> does not mention this
I consider throw_exception part of Boost Exception and so it's documented here:
The previous separate documentation should be removed.
> 4. If let's say I would like to disable Boost.Exceptions exposure during
> Boost.Test compilation, will it lead to the ODR violations?
I suppose you mean if two modules are compiled with and without the
hook enabled. Strictly speaking, the answer would be yes, but in
reality everything should work (though the test suite does not test
Normally you shouldn't disable this integration; all this hook does is
add a private base class to exceptions emitted by
Reverge Studios, Inc.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk