[exception]throw_exceptions concerns
Hi, I am trying to look closely on to the warnings emitted during Boost.Test compilation and I've noticed couple that makes me a bit concerned (these are from msvc-7.1 toolset): ..\..\..\boost\throw_exception.hpp(58) : warning C4673: throwing 'boost::exception_detail::clone_impl<T>' the following types will not be considered at the catch site with [ T=boost::exception_detail::enable_error_info_return_type<boost::bad_weak_ptr>::type ] ..\..\..\boost\detail\shared_count.hpp(407) : see reference to function template instantiation 'void boost::throw_exception<boost::bad_weak_ptr>(const E &)' being compiled with [ E=boost::bad_weak_ptr ] ..\..\..\boost\throw_exception.hpp(58) : warning C4671: 'exception' : the copy constructor is inaccessible Here is the list of my concerns: 1. What does the first one means and should we worry? 2. Does the second means that std::exception is not copy constructible? If yes can we disable it inside the header? 3. These warnings seems to be originated from the lines related to the Boost.Exception. in this regard I've got following concerns: 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 b) throw_exception documentation is now incorrect and misleading, since it does not mention this 4. If let's say I would like to disable Boost.Exceptions exposure during Boost.Test compilation, will it lead to the ODR violations? Thanks, Gennadiy
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.
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 integration.
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.
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 this case.) Normally you shouldn't disable this integration; all this hook does is add a private base class to exceptions emitted by boost::throw_exception. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
On Fri, Jan 2, 2009 at 2:37 PM, Mathias Gaunard <mathias.gaunard@ens-lyon.org> wrote:
Emil Dotchevski wrote:
Boost::exception is copy constructable but its copy constructor is protected
Doesn't the standard mandate a public copy constructor for exception types?
Yes, but you never throw boost::exception, you throw types that derive from it, which are required to have public copy constructor. You can still catch(boost::exception &), and you can still re-throw using a throw-expression with no operand (15.1.6). Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
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
On Sat, Jan 3, 2009 at 5:43 PM, Gennadiy Rozental <rogeeff@gmail.com> wrote:
Emil Dotchevski <emildotchevski <at> gmail.com> writes:
On Fri, Jan 2, 2009 at 5:19 AM, Gennadiy Rozental Can you please elaborate? If I use
boost::throw_exception( my_exception() );
How do I catch it?
Did you try catch(my_exception &)? :) The other two options are: - catch(boost::exception &) - this catches any exception emitted by boost::throw_exception. Also, see http://www.boost.org/doc/libs/1_37_0/libs/exception/doc/tutorial_transportin.... - catch(...) - you can use current_exception/exception_ptr in any catch, see http://www.boost.org/doc/libs/1_37_0/libs/exception/doc/current_exception.ht....
"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.
I'll repeat that "boost/exception/exception.hpp" does not #include anything. Other Boost Exception headers do use <typeinfo>, but the library takes the same special care as shared_ptr to work around the case when typeinfo is not supported.
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)
I read the above twice but I don't get what you're saying.
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?
Here's one thread but there were a couple more before and after it: http://www.nabble.com/-exception--library-update-to19377623.html#a19406381 Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
participants (3)
-
Emil Dotchevski -
Gennadiy Rozental -
Mathias Gaunard