
Emil Dotchevski <emildotchevski <at> gmail.com> writes:
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 design.
Can you please elaborate? If I use boost::throw_exception( my_exception() ); How do I catch it?
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.
Right. An error message was referring to the 'exception'. I guessed wrong what it means.
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).
Fine. But both exceptions have to be disabled in a header (especially since it's now compiled pretty much always)
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.
Can you please point me?
"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 integration.
It adds <typeinfo>, which may be serious, since shared_ptr takes special care to work around the case when typeinfo is not supported by underlying system.
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:
http://www.boost.org/doc/libs/1_37_0/libs/exception/doc/throw_exception.html
The previous separate documentation should be removed.
Remove it than. As of now incorrect one is the first found by google. Gennadiy