Improve Error Handling

[jhgg]

Initial discussion started in #31 -

graphql-core's exception handling is lacking. I'd like to implement a way where we can forward resolver errors to some place where they can be appropriately captured with their traceback in-tact.

It should handle sync and async resolver errors just the same.

[inklesspen]

Agreed; the 'except Exception' stuff is particularly prone to obscuring the actual problem; to find the problem in graphql-python/graphene#50 I needed to edit the graphql-core source and put in some pdb calls

[Globegitter]

Is there any update on this? Been running into issues a few times now where a stacktrace would have been very useful. Also happy to look into it with some pointers.

[jhgg]

@Globegitter - will probably be over the winter vacation time. I'm very busy at my new job ;(

[Globegitter]

@jhgg If you can give me any pointers as to where a good place is to start I would be happy to try and look into it.

[jdugan1024]

@Globegitter I didn't dig into this too deeply yet, but I believe at least part of the problem is here:

https://github.com/graphql-python/graphql-core/blob/450620de817480e5f36b64b7eb055a2be12abea0/graphql/core/execution/executor.py#L195-L197

I'm not clear enough on the internals to understand the flow of control or how one might expose the errors in the ctx object.

[defrex]

Any movement on this? It's massively problematic for me.

The ideal solution for me would be no solution. I already have error handling at the application layer that would turn the requests into 500s and appropriately log the traceback. Having a whole other way of managing errors seems unnecessary.

That said, anything would be better then the way it is now. As things stand debugging production errors is essentially impossible.

There is also a potential security issue with sending even the message line of the traceback to the user, as it could contain sensitive information.

[jdugan1024]

I agree, we need something better than the current nothing. ;-)

There is pull request #47 which was submitted by @rafales a while back. It just uses the logging module to report errors. I'm doing something similar in my dev environment. I think #47 is a good start and probably should be implemented until there is a better solution. This sidesteps the security issues for now as well.

There should be a hook so as a developer I can provide some kind of feedback to the user that something went wrong. Silently swallowing errors and returning None is very confusing.

If I get some time I'll see if I can work up an actual solution, but I'm not sure when I'll have the time.

[jhgg]

If I get some time I'll see if I can work up an actual solution, but I'm not sure when I'll have the time.

I'm in the same boat. Let me see what I can do quickly over the weekend to get out 0.4.12.2 w/ better error logging.