Re: [review][LEAF] Review of LEAF starts today : May 22 - May 31

From: Gavin Lambert (boost_at_[hidden])
Date: 2020-06-02 01:54:32

On 2/06/2020 13:15, Emil Dotchevski wrote:
> On Mon, Jun 1, 2020 at 4:36 PM Gavin Lambert wrote:
>> With exceptions we now have nested_exception, but they both might wish
>> to transport a filename, for example, and these may be different at each
>> level.
> 
> Two options:
> 
> 1) You want to capture the error objects reported by a lower level
> function, and then later look at them elsewhere. Here is an example on how
> to do this:
> 
> With exceptions:
> https://github.com/zajo/leaf/blob/master/examples/capture_in_exception.cpp?ts=4
> .
> With leaf::result<T>:
> https://github.com/zajo/leaf/blob/master/examples/capture_in_result.cpp?ts=4
> .
> 
> This is analogous to nested exceptions, the exact context type is erased
> and the context is transported in an exception or in a leaf::result<T>.

That appears to be parallel exceptions, not nested exceptions.  I don't 
think these are analogous, given that remote_try_catch appears to be 
using some kind of magic to figure out which captured context to 
inspect, but you would instead presumably need to tell it explicitly 
whether you are looking at the context of the top-level exception or the 
nested exception.

> 2) A lower level function has failed but you don't want to report this as a
> new error so to speak, you just want to add more info to the existing
> failure. Ideally the two functions would use different error types, and in
> this case it'll just work, just use preload().

For a possible use case (I'm sure there are others), imagine a "safe 
file saver" class that uses backup files.  The higher-level error 
reporting wants to report the filename that the caller was actually 
trying to save, and yet the underlying internal file API might want to 
report that the problem actually occurred when saving either the real 
file or the backup file.

Obviously the low-level function doesn't know that it's dealing with a 
backup file, so it would just have a generic e_filename.

And the higher-level function will likely want to report its intended 
filename as an e_filename as well, as that is the one the caller cares 
about.

But does that mean that it would need to (and is this even possible?) 
move the underlying low-level filename to a new e_real_filename or 
similar in order to give e_filename a different value?

This sort of thing seems like a flat error reporting model rather than a 
nested model, and flat errors tend to lose information.  (Not that C++'s 
mechanisms for nested exceptions are particularly wonderful.)

> (The reason why this is needed is that a context can hold no more than one
> object for each type. In principle this can be changed, in which case you
> could have two e_file_name stored in the same context, associated with two
> different error_ids.)

Presumably this would not be possible without either reintroducing 
memory allocation or pre-declaring the max number of possible nested 
errors either per-context or globally.