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 coercion errors to be handled by sangrias custom exception handler #252
Comments
@OlegIlyenko Any plans for this? Or can we somehow help making this happen? |
Sorry, haven't looked it in detail yet. I will try to do it soon |
@BjRo now it should be possible to define custom error handling for any kind of error, including The migration strategy before val exceptionHandler: Executor.ExceptionHandler = {
case (m, ...) ⇒...
}) after val exceptionHandler = ExceptionHandler {
case (m, ...) ⇒...
} Example Here is an example: sangria/src/test/scala/sangria/execution/ExceptionHandlingSpec.scala Lines 135 to 140 in 9a5aed8
|
@OlegIlyenko This looks pretty cool. I'm back from tomorrow and will give it a spin. The breaking change is not really a problem for us. Thank you a lot! |
I ran into this after upgrading sangria, would you be so kind to update the docs with this as well? @OlegIlyenko |
@OlegIlyenko nm that the first example didnt work, my bad. But thrown Exceptions is still handled by onViolation and onError... is that how it is supposed to work? |
Extracted from #248
This one came up during our current project. We noticed some inconsistencies in the errors we expose through our app. Just to give you an idea what our use case is: Our product basically extends sangrias errors before sending them to the client. This is mostly done for clients so that understanding
GraphQL
errors becomes less challenging for them. This includes for instance adding an error id to the error (such asRESOLVE_FAILED
, orQUERY_ANALYISIS_FAILED
). Or adding adetails
field, which further describes the error. All of our errors are handed out in the same format.This is roughly how we do it:
The new coercion error introduced by #248 would be the only one that we can't really handle that way. So the question for this issue would be, can we make this work somehow?
The text was updated successfully, but these errors were encountered: