error types should be nothrow-movable

[ericniebler]

Issue by lucteo
Sunday Nov 28, 2021 at 17:08 GMT
Originally opened as NVIDIA/stdexec#284

---

Given:

• P2300R2 description of the set_error() CPO doesn't make any reference to whether set_error() can throw or not (9.4.2). The text implies that noexcept is forwarded to the actual implementation (most probably by the receiver objects)
• The receiver concept specification (9.4) defines the set_error() CPO as noexcept
• The let_error() specification allows the type E to throw in move construct
• The let_error() implementation example (9.6.4.5) implies that set_error(E) can throw (and a subsequent set_error() is called with the caught exception).

This seems confusing.

The only way that set_error() can throw inside the operation state is when the error type throws on move.
If the E type can throw while being moved, then:

• as implementation show, we need a try/catch around the call to set_error()
• the sender construction can throw (as the error value is moved)
• the operation state can throw when constructed (i.e., when connect is called)

Again, the receiver connected to the operation state of let_error() doesn't allow set_error(E) to throw

Wouldn't it be better for the paper to specify that all error types are nothow-movable?
The paper has this requirement in several places for other types. Adding this specification will make the implementation simpler and more coherent.

[ericniebler]

Comment by lucteo
Sunday Nov 28, 2021 at 17:34 GMT

---

Looking at the libunifex implementation (https://github.com/facebookexperimental/libunifex/blob/2547d87fb98a1fe70eccc170a8c91b144648517d/include/unifex/receiver_concepts.hpp), if the error type throws on move, then the program is ill formed. The set_error() CPO is defined as noexcept, it doesn't constrain the error type to not throw, and allows the move constructor to be called on the given error.

Thus, the inner call to tag_invoke may throw, without try/catch, inside a noexcept function.

[lewissbaker]

We should discuss about having this restriction in the set_error() CPO.
i.e. that it mandates that the error type must be nothrow move-constructible.

[lewissbaker]

We discussed this in an author sync meeting.

It seems reasonable to allow error objects with throwing move-constructors as these objects can still be passed to set_error by reference. Then within the set_error implementation, it can handle any potentially throwing move-constructors by catching the exception and storing the exception_ptr instead.

This is essentially the status quo from P2300R10.

One concern with this approach was that it is potentially forcing the receiver to throw away the error information from the original error and instead propagate a different error. This is something the core language tries to avoid (albeit by terminating the program) in similar situations where an error needs to be propagated while another error is already being propagated (e.g. if initialization of exception object in catch-clause throws then program terminates, as in try { throw std::string("foo"); } catch (std::string s) {} if initialization of s throws.)

It would also force many algorithms that compose senders that can potentially complete with an error object with a potentially throwing move constructor to also add set_error_t(exception_ptr) to the completion signatures.

These concerns would need to be explored more deeply in a paper, however, as there didn't seem to be enough immediate justification for changing the status quo.