-
Notifications
You must be signed in to change notification settings - Fork 46
include key in error message from getField functions #44
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
Conversation
Thanks @crcornwell! I think this is a useful addition to the library. Just two questions:
|
|
||
infix 7 getFieldOptional as .?? | ||
|
||
defaultField :: forall a. Either String (Maybe a) -> a -> Either String a | ||
defaultField parser default = fromMaybe default <$> parser | ||
|
||
infix 6 defaultField as .?= | ||
|
||
elaborateFailure :: ∀ a. String -> Either String a -> Either String a |
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.
We should make explicit exports for the module so we don't expose this function
@thomashoneyman sure, I can add a test. As far as outputting the array index in the error message I think that should be possible using something like |
If it's possible to do it'd be fantastic to add that into this PR at the same time. If not (or if it would take significant changes) then your proposal here is already useful. |
Looks great! Glad to see both the array index and object key receiving clearer errors. Thanks for adding those extra tests to cover the new error messages, too. |
What does this pull request do?
Extends the error message returned in the
Left
result ofgetField
andgetFieldOptional
. This will take the message coming fromdecodeJson
and prepend it with a helpful message that includes the specific key that failed to decode (e.g.Value is not a String
will becomeFailed to decode 'foo': Value is not a String
).How should this be manually tested?
All tests are still passing, and this doesn't change the API in any way. To manually test you could create a
Json
value with a type that doesn't match what it should and see the new error on decode.Other Notes:
This is a very simple change that will go a long way toward making the decoding error messages more useful, however a more robust solution akin to Aeson Better Errors would be ideal. For now though, I think this should be good.