Lifecycle error catch hides underlying exception message

[mormj]

Something in start() threw an exception when instantiating an object, but it was hard to find the underlying exception because it was caught and this was shown instead.

terminate called after throwing an instance of 'gr::exception'
  what():  scheduler gr::scheduler::Simple<(gr::scheduler::ExecutionPolicy)1, gr::profiling::null::Profiler>: throwing ignored exception 2025-01-13T22:26:28.537: ../code/subprojects/gnuradio4/core/include/gnuradio-4.0/Block.hpp:824:103: constexpr void gr::Block<Derived, Arguments>::requestStop() [with Derived = gr::digital::BitScrambler<unsigned char>; Arguments = {}]: Block 'gr::digital::BitScrambler<unsigned char>#0' invalid state transition in gr::digital::BitScrambler<unsigned char> from ERROR -> to REQUESTED_STOP in method: constexpr void gr::Block<Derived, Arguments>::requestStop() [with Derived = gr::digital::BitScrambler<unsigned char>; Arguments = {}] at ../code/subprojects/gnuradio4/core/include/gnuradio-4.0/Scheduler.hpp:165

[RalphSteinhagen]

Normally, the exception is caught, only forwarded, and then rethrown if the scheduler isn't connected to a UI that handles the exception..

Which exception was thrown in start()? If gr::exception(...) is thrown, then this also includes a more precise source location.

The code above is generated by:

gnuradio4/core/include/gnuradio-4.0/Scheduler.hpp

Lines 161 to 169 in dfa78d2

	if (this->msgOut.buffer().streamBuffer.n_readers() == 0) {
	// nobody is listening on messages -> convert errors to exceptions
	for (const auto& msg : messagesFromChildren) {
	if (!msg.data.has_value()) {
	throw gr::exception(fmt::format("scheduler {}: throwing ignored exception {:t}", this->name, msg.data.error()));
	}
	}
	return;
	}

Maybe an additional \n and passing the source location std::source_location location from the gr::Error into the newly generated gr::exception many help.

The question is what is more important: whether to indicate that an exception hasn't been caught/isn't handled by the application invoking the scheduler, or what caused the initial exception (which is stored in the gr::Error object). 🤔