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: serialize dyn Error Values using collect_str #89

Merged
merged 1 commit into from Mar 8, 2022

Conversation

hawkw
Copy link
Member

@hawkw hawkw commented Mar 3, 2022

Currently, valuable-serde handles Value::Error variants incorrectly.
When valuable-serde encounters a Value::Error, it returns the error
immediately as a serialization error:

Value::Error(e) => Err(S::Error::custom(e)),

This is not correct. If a serde serializer returns an error, this
means something has gone wrong while serializing a value. Returning an
error makes the serialization fail. However, this is not what
valuable's Value::Error means. Value::Error represents that we are
recording a value which happens to be an Error, not that something
went wrong while recording the value. This means that valuable-serde
will currently return an Error (indicating that serialization failed)
any time it attempts to record an Error value, and serialization will
fail.

This commit changes valuable-serde to record the error using its
Display implementation, using serde's collect_str method. Now,
Errors will be serialized by recording their messages as a string,
rather than causing the serialization to fail.

Using collect_str allows the serializer to write the display
representation to its own internal buffer, rather than having to format
the error to a temporary String beforehand.

Fixes #88

@hawkw hawkw requested review from taiki-e and carllerche March 3, 2022 00:11
@taiki-e
Copy link
Member

taiki-e commented Mar 3, 2022

lgtm.

As for the CI (codegen) failure, I implemented a way to automatically fix that (rust-lang/futures-rs#2562), but forgot to port it to this repository. I will open a PR later.

@hawkw
Copy link
Member Author

hawkw commented Mar 3, 2022

@taiki-e great, happy to rebase this once CI is sorted out!

@taiki-e
Copy link
Member

taiki-e commented Mar 5, 2022

@hawkw: Filed #90 to fix CI issue.

Currently, `valuable-serde` handles `Value::Error` variants incorrectly.
When `valuable-serde` encounters a `Value::Error`, it returns the error
immediately as a serialization error:
https://github.com/tokio-rs/valuable/blob/1fc2ad50fcae7fc0da81dc40a385c235636ba525/valuable-serde/src/lib.rs#L267

This is _not_ correct. If a `serde` serializer returns an error, this
means something has gone wrong while serializing a value. Returning an
error makes the serialization fail. However, this is *not* what
`valuable`'s `Value::Error` means. `Value::Error` represents that we are
_recording a value which happens to be an `Error`_, not that something
went wrong _while_ recording the value. This means that `valuable-serde`
will currently return an `Error` (indicating that serialization failed)
any time it attempts to record an `Error` value, and serialization will
fail.

This commit changes `valuable-serde` to record the error using its
`Display` implementation, using `serde`'s `collect_str` method. Now,
`Error`s will be serialized by recording their messages as a string,
rather than causing the serialization to fail.

Using `collect_str` allows the serializer to write the display
representation to its own internal buffer, rather than having to format
the error to a temporary `String` beforehand.

Fixes #88
@hawkw hawkw merged commit 01a4d6a into master Mar 8, 2022
hawkw added a commit that referenced this pull request Mar 8, 2022
Depends on #89

This PR changes `valuable-serde`'s recording of `dyn Error` values to
record the error as a `serde` struct with `message` and `source` fields.
This way, we can serialize errors with source chains more nicely.

When the backtrace support for `std::error::Error` is stable, we could
also record backtraces as a field. We could even consider adding a build
script to detect the nightly compiler and conditionally enable a `cfg`
for backtrace support, but that seems better left to a follow-up.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Strange happenings with manual implementation of Valuable
2 participants