Proposal: Support richer error messages

[zachdaniel]

It would be nice to be able to:

1.) Include the key's in the error messages and
2.) Support getting all of the errors at once

I have another layer of error reporting that I pass the result of NimbleParsec.validate/2 into, and previously I was using a library I wrote https://github.com/albert-io/optimal for validating options. However, I'd rather use this, even though it doesn't have some of the features, since it is backed by a pillar of the community :D

[josevalim]

I believe we already include the key in the error message. We could also introduce a validate_all function to get all errors in a more structured way. Such as %{key: :foo, message: ...}. A PR in this direction is welcome.

[zachdaniel]

For including the key in the error message, I was thinking of something like:

{:error, {:foo, "expected a string, got: 1"}} vs the current {:error, "expected :foo to be an string, got: 1"}

I think the current behavior should be the default regardless, as its the most straightforward interface. I like the idea of validate_all. I'll see if I can work something up in the next week or two.

[leandrocp]

I had a similar issue while implementing validation for :list https://github.com/dashbitco/nimble_options/pull/35/files/f3ca27c00ebf7a244175290b8c027c31a8b2e9d2#r432874093

A list of custom function may return more than one custom error message (one for each input validation), which makes tricky to return an useful feedback if the only supported format is {:error, "a single error message here"}, so I just changed it to {:error, ["error message for input 1", "error message for input 2]} (please see the link above for an example). I like the idea of separating the internal data structure from the presentation, so each validation function could return {:error, {:field, [error_message]}} and have something like traverse_errors or even a format function to be called in validate. In short, having a more flexible internal data structure to support more validations in the future without breaking the API.

[whatyouhide]

My (strong :P) suggestion is to go with {:error, %NimbleOptions.ValidationError{}} (which already exists as an exception) and put the necessary information in there. We could put a list of errors, the key, whatever in there. It's nice because most users will do one of these:

• return the Exception.message(validation_error) message, which lets us control how to turn structured data in a nice readable message

• raise the error (what validate!/2 does today, already)

We could even make the fields of this struct private so we can change them freely for the time being. Thoughts?

[kevinkoltz]

{:error, %NimbleOptions.ValidationError{}}

This seems like a good shape for the errors (similar to Ecto.Changeset errors). If the errors are nested like Ecto.Changeset errors, then it will be easy to write reusable code for handling errors in general.