On Mon, May 25, 2020 at 7:34 AM Bjorn Reese via Boost
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).