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

Unhelpful error message when struct name doesn't match #301

Closed
cswinter opened this issue Apr 17, 2021 · 2 comments · Fixed by #354
Closed

Unhelpful error message when struct name doesn't match #301

cswinter opened this issue Apr 17, 2021 · 2 comments · Fixed by #354

Comments

@cswinter
Copy link
Contributor

When deserializing a string that defines a RON struct with an optional class name that does not match the name of the Rust struct, ron::from_str returns an error that displays as Error: 1:1: Expected struct. It took me quite a long time to figure out what the issue was. It would be more helpful if the error message was something like Error: 1:1: Expected struct "Name" but got struct "ActualName".

@Valmirius
Copy link

I'm also getting this error "Failed to load config: 1:1: Expected struct" in the decode_file.rs example via example.ron even when using the exact same files, not entirely sure why it's asking for a Struct.

@juntyr
Copy link
Member

juntyr commented Nov 19, 2021

I just had a very brief look at the codebase to see how difficult it would be to implement this. Here are my thoughts:

  1. A simple solution would be to also report the name of the struct that was expected. This would already give most of the debugging value as you could then manually look at the RON file to see what name you provided. Implementing this option is trivial.

  2. To find out if a different identifier was given instead, ron would have to check if any valid identifier but wrong identifier is given and that the opening ( exists. In the case where the only error is the wrong struct name, this could certainly be achieved, though at the cost of a bit of extra code clutter. However, any further edge cases would still give the original error messages.

Personally, I think that option (1) could be a good start as it provides most of the error reporting benefit already while requiring very few code changes and no additional code complexity. Option (2) could then still be implemented later on as a refinement.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants