Skip to content

executor: adds panic handler#253

Open
chris-ramon wants to merge 6 commits intomasterfrom
panic-handler
Open

executor: adds panic handler#253
chris-ramon wants to merge 6 commits intomasterfrom
panic-handler

Conversation

@chris-ramon
Copy link
Copy Markdown
Member

@chris-ramon chris-ramon commented Oct 22, 2017

Overview

Test plan

  • Unit test.

scottjg and others added 5 commits October 21, 2017 12:07
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.
@coveralls
Copy link
Copy Markdown

coveralls commented Oct 22, 2017

Coverage Status

Coverage increased (+0.009%) to 82.091% when pulling 47767e0 on panic-handler into 7731016 on master.

@scottjg
Copy link
Copy Markdown

scottjg commented Oct 22, 2017

@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.

@coveralls
Copy link
Copy Markdown

coveralls commented Dec 24, 2017

Coverage Status

Coverage increased (+0.009%) to 82.234% when pulling 451533e on panic-handler into 9b5a661 on master.

@jekiapp
Copy link
Copy Markdown
Contributor

jekiapp commented Feb 9, 2018

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?
I used to manually add

defer func() {
	if r := recover(); r != nil {
		log.Println("panic: ", string(debug.Stack()))
		panic(r)
	}
}()

on every resolver.
So with this handler I should print with debug.Stack() in the handler?
and also why this PR still not merged to master yet, or should I use another version for using this patch?

@rodrigo-brito
Copy link
Copy Markdown

@chris-ramon Do you have any forecast for the release?

@niondir
Copy link
Copy Markdown

niondir commented Jul 11, 2018

looking forward to get this merged.

Comment thread executor.go
if r := recover(); r != nil {

if eCtx.PanicHandler != nil {
eCtx.PanicHandler(eCtx.Context, r)
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@phifty
Copy link
Copy Markdown

phifty commented Dec 10, 2019

any updates on this?

1 similar comment
@jpascal
Copy link
Copy Markdown

jpascal commented May 8, 2021

any updates on this?

@maddsua
Copy link
Copy Markdown

maddsua commented Jul 26, 2024

Looking forward to have this merged, really need an option to add custom panic handler 👀

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Custom panic handler

9 participants