yaahc
commented
3 years ago There is probably a law that states that any open source Rust project will eventually be asked for serde support.
Anyway, to have this would be great (maybe behind a feature flag, as is tradition).
The use case for me is that I have a networked library, and I want to propagate something like
Reportback to the client, to have more meaningful errors on the client.
I'd be happy to merge serde support but I'm worried that we would be fairly limited in what support we could implement and that it might not be what you have in mind. color-eyre only provides a hook for eyre, which itself stores errors as type erased trait objects. We can't accurately serialize the source error beyond converting it into a chain of messages that we reconstruct as a different type on the other side. We could serialize the content of the EyreHandler that color-eyre provides, and a limited version of the dyn Error which is recreated lossily on the other side and hidden inside of the Report, but that's pretty much the limit. Also it wouldn't be a serialization impl directly on the eyre::Report, it would instead have to be a fallible adapter that attempts to access the handler, and if the handler is the one exported by color-eyre it grabs that context, and the error and wraps them in a type that implements Serialize.
If you're still interested in this I can help describe how to implement it but otherwise I don't expect I'll be able to make time to implement this support myself in the near term.
There is probably a law that states that any open source Rust project will eventually be asked for serde support.
Anyway, to have this would be great (maybe behind a feature flag, as is tradition).
The use case for me is that I have a networked library, and I want to propagate something like
Reportback to the client, to have more meaningful errors on the client.