----- Original Message ----- From: "Emil Dotchevski" <emil@revergestudios.com> To: <boost@lists.boost.org> Sent: Saturday, September 06, 2008 6:52 AM Subject: Re: [boost] [exception] Incompatibility between boost::throwexception and throw prototype declarations

On Fri, Sep 5, 2008 at 9:42 PM, vicente.botet <vicente.botet@wanadoo.fr> wrote:

...

Hi,

As boost::throw_exception can now throw un unspecified exception throgh the use of enable_current_exception, do it is no more possible to use throw declaration in the prototype of any function calling functions that directly or indirectly calls throw_exception. See enable_current_exception declaration in the documentation.

namespace boost { template <class T> ---unspecified--- enable_current_exception( T const & e ); }

Does it means that we have a interface change of the boost::throw function since it was implemented by the Boost.Exception library on 1.36.0?

Umm..... Whaaaat?

If G throws the excp using the boost::throw(excep) on 1.15 I was able to write void F() thows (excp) { // ... G(); // ... } With 1.136 this code do not compile any more because boost::throw_exception throws an unspecified exception. So what can I write instead of --unspecified-- void F() thows (excp, --unspecified--) { // ... G(); // ... } I hope this answer your question, let me know if it is not the case. P.S. I don't push for exception specification in function prototypes, I'm just saying that when used the new boost::throw_exception implementation brokes the code. Vicente

----- Original Message ----- From: "Andrey Semashev" <andrey.semashev@gmail.com> To: <boost@lists.boost.org> Sent: Saturday, September 06, 2008 8:59 AM Subject: Re: [boost] [exception] Incompatibility betweenboost::throwexception and throw prototype declarations

On Sat, Sep 6, 2008 at 9:16 AM, vicente.botet <vicente.botet@wanadoo.fr>wrote:

...

----- Original Message ----- From: "Emil Dotchevski" < emil@revergestudios.com> To: <boost@lists.boost.org> Sent: Saturday, September 06, 2008 6:52 AM Subject: Re: [boost] [exception] Incompatibility between boost::throwexception and throw prototype declarations

If G throws the excp using the boost::throw(excep) on 1.15 I was able to write

void F() thows (excp) { // ... G(); // ... }

With 1.136 this code do not compile any more because boost::throw_exception throws an unspecified exception. So what can I write instead of --unspecified--

void F() thows (excp, --unspecified--) { // ... G(); // ... }

I hope this answer your question, let me know if it is not the case.

If I'm not mistaken, you are safe to add base classes to the exception specification list. Since the "unspecified" exception derives from the "excep" (otherwise you wouldn't be able to catch it), I assume you don't need to change your code.

Where is specified that the --unspecified-- exception derives from "excp"? Vicente

----- Original Message ----- From: "Andrey Semashev" <andrey.semashev@gmail.com> To: <boost@lists.boost.org> Sent: Saturday, September 06, 2008 8:59 AM Subject: Re: [boost] [exception] Incompatibility betweenboost::throwexception and throw prototype declarations

On Sat, Sep 6, 2008 at 9:16 AM, vicente.botet <vicente.botet@wanadoo.fr>wrote:

...

----- Original Message ----- From: "Emil Dotchevski" < emil@revergestudios.com> To: <boost@lists.boost.org> Sent: Saturday, September 06, 2008 6:52 AM Subject: Re: [boost] [exception] Incompatibility between boost::throwexception and throw prototype declarations

If G throws the excp using the boost::throw(excep) on 1.15 I was able to write

void F() thows (excp) { // ... G(); // ... }

With 1.136 this code do not compile any more because boost::throw_exception throws an unspecified exception. So what can I write instead of --unspecified--

void F() thows (excp, --unspecified--) { // ... G(); // ... }

I hope this answer your question, let me know if it is not the case.

If I'm not mistaken, you are safe to add base classes to the exception specification list. Since the "unspecified" exception derives from the "excep" (otherwise you wouldn't be able to catch it), I assume you don't need to change your code.

I have tried with a simple example that confirm what you said. #include <boost/throw_exception.hpp> #include <iostream> struct excp : std::exception {}; void G() { boost::throw_exception(excp()); } void F() throw (excp) { try { G(); } catch (excp& e) { std::cout << __LINE__ << std::endl; throw; } catch (...) { std::cout << __LINE__ << std::endl; throw; } } int main() { try { F(); } catch (excp& e) { std::cout << __LINE__ << std::endl; } return 0; } and compiled it with both versions. Everything is OK. Sorry for the noice, Vicente

On Fri, Sep 5, 2008 at 10:16 PM, vicente.botet <vicente.botet@wanadoo.fr> wrote:

void F() thows (excp) { // ... G(); // ... }

With 1.136 this code do not compile any more because boost::throw_exception throws an unspecified exception. So what can I write instead of --unspecified--

void F() thows (excp, --unspecified--) { // ... G(); // ... }

P.S. I don't push for exception specification in function prototypes, I'm just saying that when used the new boost::throw_exception implementation brokes the code.

Consider a function declared as: class my_exception1; class my_exception2; void foo() throw(my_exception1,my_exception2); The above declaration doesn't guarantee that the function does not throw any other exceptions, only that if it throws something else the runtime will call std::unexpected(), as if: try { foo(); } catch( my_exception1 ) { throw; } catch( my_exception2 ) { throw; } catch(...) { std::unexpected(); } This works regardless whether foo throws via enable_error_info or uses the throw statement directly. The only observable difference between throw A(); and throw enable_error_info(A()) is that in the latter case the exception can be caught not only as A but also as the unspecified type returned by enable_error_info(A()), which is why the type is not specified (you can't catch it if you don't know what it is.) I suppose you could think of other "differences", like the fact that enable_error_info lets you throw a type that would be abstract without the wrapper returned by enable_error_info, etc. Anyway, what's your point? :) Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode