signals2/signal.hpp does not compile with exceptions off

[peterpastor@…]

boost/signals2/signal.hpp includes boost/signals2/detail/slot_call_iterator.hpp

which uses throw (instead of boost::throw_exception as it should)

with exceptions off, you cannot use throw(), try, catch, etc., hence BOOST_TRY, BOOST_CATCH, BOOST_RETHROW

[Frank Mori Hess]

The proposed change may make it compile, but IIRC it will break automatic slot disconnection when compiling without exceptions. Boost libraries are not required to work without exception support. I'm leaving this ticket open as a feature request, but I have no immediate plans to resolve it.

[gromer@…]

I don't see how this can break automatic slot disconnection. The presumption is that boost::throw_exception either throws an exception (no change from the current code) or terminates the program (which makes slot disconnection a moot point).

Many large codebases are built without exceptions; whether or not Boost is required to support them, it's a major deficiency for it not to. Why not just take the fix, when it's so trivial?

[Frank Mori Hess]

Perhaps I should have said "break the program when it tries to use automatic slot disconnection"? Signals2 causing the program to terminate when the signals2 is used as it is documented to be used is about as broken as broken gets.

[gromer@…]

Oh, I see what you're saying: Signals2 relies on this exception for non-exceptional control flow. That being the case, yes, Signals2 shouldn't compile with exceptions disabled, but that means we have the opposite problem: it doesn't fail to compile reliably enough. It looks like Clang will compile this code just fine with exceptions disabled, and although it doesn't compile in gcc, I would argue that's a bug. The line of code at issue is a re-throw inside a catch block, so it's harmless when exceptions are disabled, because it will never be reached.

In any event, this is the wrong place for the error to occur: the code that makes Signals2 unsafe with exceptions disabled is the code that "swallows" exceptions: the catch blocks that don't re-throw in last_value.hpp and optional_last_value.hpp. Those whole functions (or the whole files, like boost/thread/future.hpp) should be wrapped in #ifndef BOOST_NO_EXCEPTIONS.

[gromer@…]

Scratch that last update; I was talking out of my ass.

[gromer@…]

Why does Signals2 use boost::throw_exception() where the exception is originally thrown? boost::throw_exception() is tantamount to abort() when exceptions are disabled, so it seems like it shouldn't be used for conditions that are expected to occur in normal use.

[Frank Mori Hess]

Replying to gromer@…:

Why does Signals2 use boost::throw_exception() where the exception is originally thrown?

I've removed all usage of boost::throw_exception from develop.

[Frank Mori Hess]

signals2 should be mostly usable now without exceptions, the changes will be in 1.62.