Improve config file parsing error messages

[borsboom]

For example, if I put install-ghc: 123 in a stack.yaml, I get this not very informative error:

$ stack exec true
AesonException "when expecting a Bool, encountered Number instead"

We should at least catch AesonExceptions when parsing the config files and wrap them in our own "ConfigParseFailedException" (or something like that), and include the path to the config file where the failure occurred in the message. If there was a way to get Aeson to report the field with the error that would be even better (I don't know if that's possible though).

• Include field with error in AesonException.
• Include config file path in error message.
• Include link to config documentation in error message.

[snoyberg]

I agree. This is also related to #48.

[chrisdone]

Possible avenue: https://github.com/chrisdone/descriptive#self-documenting-json-parser

[snoyberg]

No objection from me.

[radix]

I commented about some stuff with config file parsing in #211, but this ticket is more clearly more appropriate for my suggestion, so I'll just restate it here:

There's now a wiki page (still in progress) documenting everything about stack.yaml here: https://github.com/commercialhaskell/stack/wiki/stack.yaml

I recommend that all config-file parsing errors show a link to this page, and if possible, a specific subsection about whatever directive couldn't be parsed.

[gregwebs]

The way I have tackled this in the past is to just override the .: etc operators to give they key in the failure message. I do this where Aeson is imported into the project (Import.Aeson or Aeson.Extended or whatever your preferred approach is there). The link to the wiki can probably be added by using modifyFailure. I would suggest first seeing how much this approach improves the situation before using a new parsing library.

[gregwebs]

Addressed by #284. Here is the output I get from that.

AesonException "failed to parse field install-ghc: when expecting a Bool, encountered Number instead"

Including both the path to the config file and a link to the wiki documentation of the YAML config should be done, but perhaps a separate issue can be opened for that?

[borsboom]

Probably can leave this issue open to address the rest (I've added steps to the top comment), but I have no objection to merging the pull request. Thanks!