-
Notifications
You must be signed in to change notification settings - Fork 322
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
base: master
Are you sure you want to change the base?
Better invalid json message (issue #558) #559
Conversation
I think it should read in this order The |
_ | w >= 48 && w <= 57 || w == 45 | ||
-> Number <$> scientific | ||
| otherwise -> fail "not a valid json value" | ||
value = parser <?> "valid json" |
There was a problem hiding this comment.
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) |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
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. |
See #558.
First pass. Since these shows all errors for parses named with
<?>
it leads to some other jankiness: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.