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

Provide an easy way to customize only the error message #1883

Closed
yaymukund opened this issue Sep 1, 2020 · 0 comments · Fixed by #1916
Closed

Provide an easy way to customize only the error message #1883

yaymukund opened this issue Sep 1, 2020 · 0 comments · Fixed by #1916

Comments

@yaymukund
Copy link

yaymukund commented Sep 1, 2020

EDIT After thinking about it some more, I feel it would be better to improve this error message rather than add API surface area. #1544 gets close, but I believe those errors are still too opaque for Cargo's purposes, and it's hidden behind a flag. Anyway, my original post:


I have an untagged union:

#[derive(Serialize, Deserialize)]
#[serde(untagged)]
enum MyEnum {
  Foo(Vec<String>),
  Bar(usize)
}

If all variants fail, you get this error message:

"data did not match any variant of untagged enum {}",

Is there a good way to customize the error message but keep the default #[derive(Deserialize)] implementation? Perhaps a new attribute?:

#[serde(untagged, expecting = "a number or a list of strings")]
enum MyEnum {
  ...
}

Advantages:

  • You don't have to reimplement Deserialize
  • Concise

Disadvantages

  • How common is this use-case? We have to do this a couple of times within Cargo.
  • Is there a better solution I am overlooking?
@yaymukund yaymukund changed the title Idea: Provide an easy way to customize only the error message Provide an easy way to customize only the error message Sep 2, 2020
Mingun added a commit to Mingun/serde that referenced this issue Oct 22, 2020
bors added a commit to rust-lang/cargo that referenced this issue Mar 20, 2021
Use serde's error message option to avoid implementing `Deserialize`.

This is a cleanup based on serde-rs/serde#1883, which fell out of #8664

It looks like this changes the resulting error messages. I'll leave it up to you to decide if the tradeoff makes sense here. Maybe the correct answer here is to make `serde`'s error messages include more details (e.g. `invalid type: int`).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
1 participant