Can we get better error messages? #113

Closed
nh2 opened this Issue Mar 27, 2013 · 13 comments

Comments

Projects
None yet
8 participants

nh2 commented Mar 27, 2013

Today I tried to decode a "1" to an Int, but it failed, because apparently only objects and arrays are top-level JSON (this is not said explicitly on http://json.org though).

eitherDecode ("1") :: Either String Int
Left "Failed reading: satisfy"

This took me quite some time. Is it possible to have slightly more informative error messages than this?

pjones commented Apr 16, 2013

In a similar vein, it would be nice to have the ability to attach error labels similar to how the (<?>) operator works in Parsec/Atto.

I'm decoding a set of records that are nested within one another and it would be nice to annotate failures so I know which nesting failed to decode.

nh2 commented Apr 22, 2013

You can actually use <?> to do that. I've been looking into making some small changes that make your above error more usable, showing the trace of <?> that attoparsec creates for you anyway, as well as telling you which unexpected character it encountered.

pjones commented Apr 24, 2013

Is that because the Parser type is actually just Parser from
Attoparsec? I swear last time I looked at the code Parser was a
type defined in Aeson using continuations.

ellis commented Dec 30, 2013

I'd also really appreciate error messages that indicate where and what the problem is!

@ghost

ghost commented Jun 29, 2014

I think this is an issue in attoparsec. relevant pull requests: #210, bos/attoparsec#71

Contributor

maximkulkin commented Sep 23, 2014

I have created a patch that should improve error reporting (#220) although in a slightly different situations than the original report in this issue.

Owner

bos commented Jul 21, 2015

This is now resolved.

>>> eitherDecode "[]" :: Either String Int
Left "Error in $: when expecting a Int, encountered Array instead"

@bos bos closed this Jul 21, 2015

nh2 commented Jul 22, 2015

Nice!

Contributor

maximkulkin commented Feb 22, 2016

@maeehart Version of Elm programming language/compiler/platform has nothing to do with version of Haskell JSON library (this library). From the source code of elm-package you can clearly see that as of version 0.16 it still uses "aeson >= 0.7 && < 0.9" (https://github.com/elm-lang/elm-package/blob/0.16/elm-package.cabal#L57). You should write an issue to elm-package to update version of aeson library to 0.10 or higher to resolve this.

@sjakobi sjakobi referenced this issue in commercialhaskell/path Jun 16, 2016

Merged

Add aeson instances #23

@ghost

ghost commented Jun 29, 2017

I hope these are still read..

I had an issue today where I saw this error. Having never seen it before (and seeing here that it was 'fixed' - although not applicable to my situation) 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, rather than just saying Error in $: 34: Failed reading: satisfy?

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

Contributor

phadej commented Jun 29, 2017

@joeshanahant

L.Fail _ _ msg -> Left ([], msg)

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).

Collaborator

bergmark commented Jun 29, 2017

@joeshanahant please file a new issue for this! I consider all uninformative error messages bugs.

@ghost

ghost commented Jun 29, 2017

Done 👍

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