Skip to content

FEATURE: Store all error objects when verbose_diagnostic_info is in try_handle_all handlers #56

@Snarpix

Description

@Snarpix

Currently verbose_diagnostic_info is storing only strings received from applying operator<< to object, and only first time the type has encountered.
From the docs:

The message printed by operator<< includes the message printed by error_info, followed by information about error objects that were communicated to LEAF (to be associated with the error) for which there was no storage available in any active (these error objects were discarded by LEAF, because no handler needed them).

If I have some error context that is manipulating error object context using following .load overload:

f it is a function that takes a single argument of some type E &, that function is called with the object of type E currently associated with *this. If no such object exists, a default-initialized object is associated with *this and then passed to the function.

In that case verbose_diagnostic_info will print the string from deepest on_error in the stack, because to string conversion is happening on MyError creation.
auto load = leaf::on_error([](MyError& e) { e.append("Ctx1")} );

Since verbose_diagnostic_info is used for debug purposes, It looks like it may allocate storage for each error object on heap and apply operator<< to object only when user calls operator<< on verbose_diagnostic_info.

If this is not suitable for some reason, may be we can add heap_diagnostic_info that will allow to store error object dynamically, and inspect them.

This will be very useful, in application development, because you may never know what error object the underlying lib is using.

Another option is to add something like try_handle_all_heap, that receives only one handler as an argument that allows runtime inspection of error objects.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions