Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Serde support #85

Open
torsteingrindvik opened this issue Jul 9, 2021 · 2 comments
Open

Serde support #85

torsteingrindvik opened this issue Jul 9, 2021 · 2 comments
Labels
duplicate This issue or pull request already exists enhancement New feature or request help wanted Extra attention is needed

Comments

@torsteingrindvik
Copy link

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 Report back to the client, to have more meaningful errors on the client.

@yaahc
Copy link
Collaborator

yaahc commented Jul 9, 2021

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 Report back 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.

@yaahc yaahc added enhancement New feature or request help wanted Extra attention is needed duplicate This issue or pull request already exists labels Feb 4, 2022
@yaahc
Copy link
Collaborator

yaahc commented Feb 4, 2022

Duplicate of #77 (kinda)

@yaahc yaahc marked this as a duplicate of #77 Feb 4, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
duplicate This issue or pull request already exists enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

2 participants