Boost logo

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