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?t... . 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.