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

Better invalid json message (issue #558) #559

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Better invalid json message (issue #558) #559

wants to merge 2 commits into from

Conversation

JoeMShanahan
Copy link

@JoeMShanahan JoeMShanahan commented Jul 9, 2017

See #558.

First pass. Since these shows all errors for parses named with <?> it leads to some other jankiness:

> eitherDecode "{ 3" :: Either String Value
Left "Error in $: Failed reading: satisfy, valid json, 34"

The "34" refers to a double quote character and comes from https://hackage.haskell.org/package/attoparsec-0.13.1.0/docs/src/Data-Attoparsec-ByteString-Internal.html#word8

Suggestions welcome. I feel like this is slightly better but this could potentially be even more confusing.

@Lysxia
Copy link
Collaborator

Lysxia commented Jul 10, 2017

I think it should read in this order "valid json, 34, satisfy", or the other way around, the reason being that the error comes from value' calling word8 calling satisfy.

The 34 and satisfy parts of the message suggest some improvements to be made in attoparsec rather than in aeson: word8 could be more descriptive, saying instead something like "expected character 34 (")", and satisfy (or a new version of it) could require an error string (which word8 would provide, thus removing the (<?>) wrapper) instead of providing an uninformative "satisfy" error.

_ | w >= 48 && w <= 57 || w == 45
-> Number <$> scientific
| otherwise -> fail "not a valid json value"
value = parser <?> "valid json"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"valid json" is indeed misleading, since the error is that the JSON is in fact invalid, but that's easy to change of course. Another issue is that annotating this recursive parser is going to result in large stacks of duplicated "valid json" strings when parsing nested structures like "[[[[[[[[[[[[[[[[[[[[[[[". Instead, you can insert this error string just in eitherDecodeWith, or perhaps add more descriptive information here, such as the current position, that may become quite heavy. It can be helpful as well, for instance by indicating where the potential mismatched brackets are, but there may also be a more lightweight solution.

@@ -257,7 +262,8 @@ eitherDecodeWith p to s =
L.Done _ v -> case to v of
ISuccess a -> Right a
IError path msg -> Left (path, msg)
L.Fail _ _ msg -> Left ([], msg)
L.Fail _ namedFailures msg -> Left ([], failMsg)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe also add the first component of Fail (position?) in the error message.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@bergmark
Copy link
Collaborator

Don't mind the benchmark failure, it's unrelated. I tried to fix it yesterday but travis was confusing me.

It would be nice to have some tests that show what the error messages will look like now for simple cases and some more complex ones. Like @Lysxia mentioned it might have some unwanted consequences.

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.

3 participants