Uninformative invalid JSON error

Error in $: Failed reading: satisfy

I had an issue today where I saw this error. Having never seen it before it took me some time to track down what my problem was.

It was a simple case of my JSON not being valid after me making an innocent minor change after already checking for validity. Is it possible for Aeson to at least state that the attempted parse failed because the supplied JSON is invalid.

If someone could point to the place where this is handled I could have a go at doing it myself?

Orignally discussed here: #113 (comment)

[phadej]

@JoeShanahanT https://github.com/bos/aeson/blob/2bc6f22f164d172d0d77d878422b67433a57a9d8/Data/Aeson/Parser/Internal.hs#L260

The satisfy is in the msg which we get from attoparsec. Maybe adding <?> in json and value parsers above in the file could improve some of the errors too (i.e what is not satisfied).

[bergmark]

If you don't end up sending a PR then please provide a reproduction.

[phadej]

Prelude Data.Aeson> eitherDecode "{ 1 " :: Either String ()
Left "Error in $: Failed reading: satisfy"

I won't be able to submit something until Monday at the earliest, if that's fine then leave it to me otherwise please feel free to fix this.

[phadej]

@JoeShanahanT as I said previously, I think it shouldn't be hard to fix this. Which makes this a perfect first-time contributor issue. Please hack on this when you have time. No need to hurry.

[JoeMShanahan]

Moving on from my work centric account, I'm here for now! I'll take a look at this over the weekend as I didn't get around to do it previously!

[JoeMShanahan]

@phadej

I've littered <?> in many places, leading to no change in the error message.

Looking at the following, I don't see how this would come into play anyway?

https://github.com/bos/attoparsec/blob/36b2adc4ca869550c4c9feb7427e267126eb78c4/Data/Attoparsec/Text/Internal.hs#L109
https://github.com/bos/attoparsec/blob/36b2adc4ca869550c4c9feb7427e267126eb78c4/Data/Attoparsec/Internal/Types.hs#L154

[bergmark]

Can we modify the message using something like modifyFailure?

[JoeMShanahan]

Does this actually avoid failure though? Something underneath is calling satisfy which bails with fail "satisfy" which in turn is directly given in the error message. Unless I'm misunderstanding, I don't know how that would help?

[Lysxia]

@JoeMShanahan

(<?>) modifies the "strs" argument of the failure continuation.

In the line phadej linked to earlier, that argument is discarded (parse puts that strs in the second component of the Fail constructor, which is matched with a wildcard here). That's why (<?>) seemingly had no effect.

[JoeMShanahan]

Ah, thanks that'll give me more to go!