Add support for custom error handlers #207
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR aims at being a more concise way of handling errors while resolving a query.
It relates to #60 and #49. The latter has no documentation at all so it is unclear how to interact with it.
Also, this PR adds tests to this feature which may also be used as a reference. Motivation behind this:
Augment/Hide Implementation Details
If you use a stacktrace library you may not want to share that information with API consumers, or maybe you want to add more information to the error
Server-side Logging
graphql-go swallows the errors and nothing gets logged on the server side. This gives developers the opportunity to do that too.
--
An error handler must be of type
type ErrorHandler func(error) *QueryError
. A default handler is provided making this feature opt-in and backwards compatible.The basic principle is to use
SchemaOpts
to augment the schema. Basic usage:Hope it helps.