API for error handling library advice

[Ddystopia]

Hello, I am working on no-alloc library that would be both type safe, ergonomic and have context traces like anyhow does. So far it looks really great, I require a special context (instead of an allocation) and keep a PhandomData<E> to provide the error which is placed inside the context.

What I want to ask is how should errors be merged? Scenario: you have 3 futures that run concurrently inside join and return errors of my library. From my experience, I would use those 3 errors in a way to produce a single error that will describe all failures - thus I decided that I will discard those 3 errors and keep the new error. But I still want all stack traces to be available... They would like merge at that point, so it would be a tree instead of the stack.

For a single error my output is like for anythow:

Error: Foo

Caused by:
    A
    B
    ...

But how should I print the tree? If I were having old errors, it might have beed good to first print out them and their parts of context stacks, then a merged error, then their common parts of the context stack. But I don't wan't those errors because all info will already be in the merged error (by my experience) and this is no-alloc environment, so I would like to remove them from the context to save space.

I have an idea to just store their full typenames, but I don't know, it seems hacky...

Any ideas? Advice? For printing a final merged error and a tree of contexts in a comprehensible manner, without including full intermediate errors?

[nerditation]

if I read your description correctly, your idea sounds similar to the error-stack crate, but implementation wise, error-stack uses type erasure to store the "source" chain, and thus requires allocation. each entry in the chain is called a Context, and the individual Context type doesn't need to store their own "source" field.

as an optimization for common case, the Report type is parameterized by the type of the "top" of the error chain, so accessing the direct error context dosen't need downcasting.

however, since you mentioned you don't want allocation, I don't think the technique is applicable in your case.

one alternative idea is to use visitors to traversal the context tree instead of providing a .source() accessor like the standard Error trait does. you can check out the derail crate for an implementation of this idea.