Graphql-tools: Swallowing errors in resolver.

[richburdon]

If I throw an exception in a resolver the error is swallowed somewhere in the graphqlExpress => makeExecutableSchema stack. Indeed the latter's docs (http://dev.apollodata.com/tools/graphql-tools/generate-schema.html#makeExecutableSchema) state:

logger is an optional argument, which can be used to print errors to the server console that are usually swallowed by GraphQL.

What's the best practice to catch these errors and return, say, a 500 response (rather than just formatting the error via formatError)?

[DxCx]

well, basiclly if you will look it architecture wise,
the 500 response should happen if transport fails,
in your case transport succeed, and then the resolver on the graphql layer failed,
so the exception is swelled and converted into graphql error in ExecutionResult,
so, TLDR: this is the correct approach, why would you want to do otherwise?

[richburdon]

Hi @DxCx

TLDR: this is the correct approach, why would you want to do otherwise?

500 means "internal server error" (below); nothing to do with the transport.

So my interpretation is that if the server throws an exception (e.g., due to a programmatic error), then this is the appropriate response. Now the server code could choose to catch these exceptions and return a different error...

BUT I don't see where we could even catch these exceptions in the current API.

https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
10.5.1 500 Internal Server Error

[DxCx]

HTTP Status code, means HTTP, again, thats the transport.
No matter which status it returns, thats the transport layer status.

On top of that, there is GraphQL, in your case, graphql resolver fails, which is the next layer on top of HTTP.

Then, the error is returned on GraphQL layer.. as errors..

GraphQL doesnt define HTTP as the transport, what do you expect to happen if your scheme will be running on top of another transport?

Im only trying to understand whats the motivation here because maybe there is a proper solution..

[DxCx]

@richburdon ?

[j]

I think I see what @richburdon is trying to accomplish. When using something like "apollo-errors" with schema stitching, errors don't work because it's eating the error up.