|
Boost : |
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2020-05-25 20:21:32
On Mon, May 25, 2020 at 7:34 AM Bjorn Reese via Boost <boost_at_[hidden]>
wrote:
> In the noexcept case, what happens in the Error-Handling function if the
> error_id generated by the Error-Reporting function is lost by the
> intermediate functions?
>
You mean, as in:
leaf::result<float> f(); // Returns a float or an error
leaf::result<int> g() // Returns an int or an error
{
(void) f(); // Discard the float or the error returned by f
return 42;
}
void error_handler()
{
leaf::try_handle_all(
[ ]
{
LEAF_AUTO(answer, g());
.... // Success! Use answer.
},
.... // Handle errors
); // Done handling errors, the context in the scope of try_handle_all is
destroyed.
}
At the time control returns back to our error_handler, any error objects
that were passed by f to LEAF are stored in a context (or, in case there
weren't any error handlers that need them, were discarded on the spot).
When the context in the scope of leaf::try_handle_all is destroyed, its
contents are destroyed as well.
To access an error object when handling errors, you need the correct
error_id. Had g reported another failure after discarding whatever f
returned, when that error reaches our error_handler, if the context still
contains any error objects associated with the error_id g discarded, they
can't be accessed because the new error has a different error_id.
You get a unique error_id when you call leaf::new_error. It's like a serial
number of this particular failure. You can print error_ids in diagnostic
messages; this can help detect bugs where a failure was erroneously
discarded (not handled).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk