executor: adds panic handler#253
Conversation
Allows you to define a function that gets called if a resolver or mutation panics
Keep the comments for the recommended public API `graphql.Params`.
We want to have it as type, since it is used in more the one place, and lib users will want to used it as well.
restore previous error handling implementation
This changes removes additional panic handler calls, we want to call it only once, and when there is a panic call while resolving a field.
|
@chris-ramon thanks for your help with this patch! i was going over your changes and i have a question... originally my patch would only call the panic handler on an actual panic. it appears with your changes, it gets called when a resolver returns any errors (maybe due to reverting the change here b63c4f0#diff-58bccd1b2cfaf06d4d4ac893e4712c88L592 ). was that intentional? if so, is it possible to distinguish between a panic and an error in the panic handler? i think everything gets flattened to a graphql formatted error type so i'm not sure if it's possible. |
|
I stuck around on this problem also, I need to know where the stacktrace of the panic in my resolver. is this patch possible to solve that? on every resolver. |
|
@chris-ramon Do you have any forecast for the release? |
|
looking forward to get this merged. |
| if r := recover(); r != nil { | ||
|
|
||
| if eCtx.PanicHandler != nil { | ||
| eCtx.PanicHandler(eCtx.Context, r) |
There was a problem hiding this comment.
It will capture all erros from GraphQL. If you see here. All errors was given by panic(). Changing the return to value (error), can solve the problem.
|
any updates on this? |
1 similar comment
|
any updates on this? |
|
Looking forward to have this merged, really need an option to add custom panic handler 👀 |
Overview
PanicHandlertype.Params.PanicHandlerfield.Test plan