Skip to content
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

Allow for customized/templated error hash creation #6

Open
jney opened this issue Aug 18, 2017 · 4 comments
Open

Allow for customized/templated error hash creation #6

jney opened this issue Aug 18, 2017 · 4 comments

Comments

@jney
Copy link
Contributor

jney commented Aug 18, 2017

Hello. Maybe i missed it in the documentation, is there a way to customise error adding fields?

@ziprandom
Copy link
Owner

I don't understand what you mean. Whenever a resolve method raises an error the resolved field is set to nil and an error is added to the response with the message of the raise.

@jney
Copy link
Contributor Author

jney commented Aug 19, 2017

i will try to be more explicit. some people are customizing error fields, for example: https://medium.com/@tarkus/validation-and-user-errors-in-graphql-mutations-39ca79cd00bf
so i was wondering if this kind of thing could be accomplished

@ziprandom
Copy link
Owner

ziprandom commented Aug 21, 2017

This is an interesting feature which is unavailable in the current implementation as it only tracks Errors with a path and a message in the form of a Tuple alias Error = { message: String, path: Array(String|Int32) }. This architecture could be changed to track a path and an Exception (which really could be any user defined subclass of Exception) and then provide functionality for a user defined callback to render the array of errors into the a hash of the desired the form. I don't know what priority to give to such a feature..

@ziprandom ziprandom changed the title error handling Allow for customized/templated error hash creation Aug 21, 2017
@Stanislav-Lapata
Copy link
Contributor

For earlier I apologize I do not know English
exceptions slower it is better to use a class or format:
GraphQL::Error/GraphQL::ResponseError
or
{:error, data} aka Elixir

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

No branches or pull requests

3 participants