Boost C++ Libraries: Ticket #11461: signals2/signal.hpp does not compile with exceptions off

attachment set

peterpastor@… — Thu, 09 Jul 2015 18:15:22 GMT

attachment → slot_call_iterator_throw_bug.diff

type changed

Frank Mori Hess — Fri, 10 Jul 2015 19:50:42 GMT

type Bugs → Feature Requests

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@… — Wed, 15 Jul 2015 17:25:08 GMT

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?

cc set

gromer@… — Wed, 15 Jul 2015 17:31:02 GMT

cc gromer@… added

Frank Mori Hess — Wed, 15 Jul 2015 17:34:32 GMT

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@… — Wed, 15 Jul 2015 18:55:19 GMT

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@… — Wed, 15 Jul 2015 20:11:10 GMT

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

gromer@… — Thu, 16 Jul 2015 21:26:11 GMT

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 — Tue, 21 Jul 2015 15:25:46 GMT

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.

status changed; resolution set

Frank Mori Hess — Sun, 15 May 2016 04:18:33 GMT

status new → closed
resolution → fixed

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