No line numbers in errors

[andrewspode]

I see this issue here complaining of lack of traceback, apparently fixed in 1.0.2
#23

My experience on 1.0.5 is that I only get a text representation of the error, and no line number of where the problem lies, which makes debugging very hard.

name 'error' is not defined

GraphQL request (32:2)
31:
32: {info}

I only get the place in the query that it's failed - which doesn't help enough.

[Cito]

Can you post a small example with code, actual output and expected output?

[andrewspode]

        if result.errors:
            data['errors'] = []
            for err in result.errors:
                data['errors'].append(str(err))
                logger.error(err)
                # TODO: This should be going to logger
                traceback.print_tb(err.__traceback__)

This is likely a weakness in my Python understanding - I was expecting the traceback to added to logger through logger.error(err). In the end, I got the trackback from the error object as above.

I would have thought that the text representation of the error would at least have the file and line number (not the full traceback), or am I wrong in that assumption?

There doesn't seem to be anything in the manual regarding error handling, nor the anatomy of the GraphQL error object, unless I'm mistaken?

[Cito]

@andrewspode Line numbers in Python code are part of the traceback which is not part of the string representation of an error. You can create your own logging Formatter that includes the traceback if you want (google for some examples). Or you can also raise the error and call logger.exception(err) instead of logger.error(err) in the exception handler.

The reference on Read the Docs was broken. The anatomy of the GraphQL error object is here now: https://graphql-core-next.readthedocs.io/en/latest/modules/error.html

GraphQL-core is the low-level library that provides the errors - everything else regarding error handling should be implemented and documented on the levels higher up which are implementing the GraphQL server (packages like Graphene-Django), depending on the environment (development, production etc.)

[messa]

I think this would add the traceback to the log message: logger.error(err, exc_info=err) st 12. 6. 2019 v 12:02 odesílatel Andrew Spode <notifications@github.com> napsal:

…

if result.errors: data['errors'] = [] for err in result.errors: data['errors'].append(str(err)) logger.error(err) # TODO: This should be going to logger traceback.print_tb(err.__traceback__) This is likely a weakness in my Python understanding - I was expecting the traceback to added to logger through logger.error(err). In the end, I got the trackback from the error object as above.

[Cito]

@messa Nice! That looks like the simplest solution. Just looked it up in the Python docs:

There are three keyword arguments which are inspected:

• exc_info which, if it does not evaluate as false, causes exception information to be added to the logging message. If an exception tuple (in the format returned by sys.exc_info()) or an exception instance is provided, it is used; otherwise, sys.exc_info() is called to get the exception information.
• The second optional keyword argument is stack_info, which defaults to False. If true, stack information is added to the logging message, including the actual logging call. Note that this is not the same stack information as that displayed through specifying exc_info: The former is stack frames from the bottom of the stack up to the logging call in the current thread, whereas the latter is information about stack frames which have been unwound, following an exception, while searching for exception handlers.
• The third optional keyword argument is extra which can be used to pass a dictionary which is used to populate the __dict__ of the LogRecord created for the logging event with user-defined attributes. These custom attributes can then be used as you like. For example, they could be incorporated into logged messages.

[andrewspode]

I had previously tried using sys.exc_info() but because I wasn't handling the original error, it gave me no results.

@messa - your solution is by far the simplest and neatest - thank you!

Glad to see Errors are back in the documentation - that clears some things up. Hopefully this thread will come up in Google for other people suffering with the same issue - it's very hard to debug resolvers without line numbers! Alternatively, a little paragraph on this in your documents wouldn't go amiss.

[miracle2k]

graphql-core@2 used to, as for as I can see, log stack traces of Python errors automatically, and @3 no longer does. I think that is a real loss; Often, an exception message just does not tell you where the error is, and having to go in and manually figure out how to use the traceback module to access the stack trace is unnecessarily complicated.

[Cito]

@miracle2k: As messa pointed out, it suffices to call logger.error(err, exc_info=err) to log the stack traces, you don't need the traceback module.

[miracle2k]

@Cito Maybe so. But still, I think this is decidedly a downgrade in the dev experience compared to @2. Literally every developer is going to have an exception in a resolver at some point, would not see any useful output on the console, and would then have to figure out how to see what is going on, and how to fix it.

Maybe in the future, when adapted to @3, libraries such as graphql-server-core, flask-graphql would do the logging, but why should they commit to use of the logging module to output exceptions, when they can equally claim to be generic libraries, and error reporting should be up to the user.

I mean I can see both sides here, but it was certainly very frustrating to deal with this when upgrading.