core: MainThreadExecutor lets non-std::exception throws escape the pump, contradicting three of its own doc comments

[Yaraslaut]

Summary

MainThreadExecutor::runTask catches only const std::exception&. Its sibling ThreadPoolExecutor::loop catches that and .... Three doc comments on the MainThreadExecutor side promise the behaviour only the pool actually implements.

Verification status

Verified by reading; not reproduced. Revision: origin/master adfe8e5f plus this branch's doc-only commits.

include/morph/core/executor.hpp:211-217:

void runTask(std::function<void()> task) {
    try { task(); }
    catch (const std::exception& exc) { ::morph::log::logError("[main-thread] callback threw: " + …); }
}

include/morph/core/executor.hpp:105-113 (the pool):

try { task(); }
catch (const std::exception& exc) { ::morph::log::logError("[thread-pool] task threw: " + …); }
catch (...)                       { ::morph::log::logError("[thread-pool] task threw unknown exception"); }

The three claims it breaks

• :147-149 (runFor) — "Exceptions thrown by tasks are logged and execution continues with the next task." A non-std::exception unwinds out of runFor, abandoning the rest of the pump window.
• :171-172 (runOnce) — "pops exactly one task, runs it, and returns true whether or not that task threw". The function does not return at all in that case.
• :194-201 (drain) — inherits the same, and leaves the queue undrained.

The asymmetry between two executors in the same header, with the pool's catch (...) carrying its own deliberate log message, reads as an oversight rather than a policy difference.

What would change the verdict

• Close it if letting a non-std::exception escape the GUI pump is deliberate (e.g. so it reaches Qt's handler) — in which case the three doc comments need correcting instead, and the divergence from ThreadPoolExecutor deserves a sentence.
• Fix is one catch (...) arm mirroring the pool's.

[Yaraslaut]

Triage: triage: valid, bug, area: core

Premise re-checked by reading both executors side by side. MainThreadExecutor::runTask (executor.hpp:211-217) has one catch (const std::exception&) arm. ThreadPoolExecutor::loop (:105-113) has that arm and a catch (...) with its own deliberate log line. Confirmed by direct read of both.

This is an asymmetry inside one header, not a policy split. That the pool arm exists, and carries its own distinct message, is the evidence that the omission is an oversight rather than a decision to let non-std::exception reach the GUI loop.

Three doc claims are falsified by it, all in the same file: runFor (:147-149) "execution continues with the next task", runOnce (:171-172) "returns true whether or not that task threw" — the function does not return at all — and drain (:194-201), which leaves the queue undrained.

Invariant 7 for the fix: a regression test must throw something that is not derived from std::exception (a bare int, or a custom type), and assert the pump continued. A test throwing std::runtime_error would pass today and prove nothing.

Low severity, unambiguous direction: one catch (...) arm mirroring the pool's.