Error handling puts JSON string into error message

[tettoffensive]

https://github.com/prisma-labs/graphql-request/blob/777cc55f3f772f5b527df4b7b4ae5f66006b30e9/src/types.ts#L29

This behavior seems really strange to me. I would thing the error message would just contain the error message, not a stringified version of the JSON which is both hard to read and parse. If someone finds this useful maybe it could be under a different key and keep message as is.

[davekiss]

Agreed, this non-standard approach is difficult to test against and makes user-friendly error messages on the client almost impossible. Is there an alternative plan or approach to offer access to the original error object?

[gabrielgatu]

Hey I just found out some interesting things playing with the error response and trying to extract the error from the response:

typeof error === 'object'

and this brought me to:

JSON.parse(JSON.stringify(error))

which returned me:

{ response: {..}, request: {..} }

And this allowed me to access the error: JSON.parse(JSON.stringify(error)).response.errors[0].message

This is super counterintuitive, but I'm glad I found a cleaner way to get the error message instead of using a regex or manipulating the string itself.

Hope it can help others as well :)

[fishactual]

This is strange behaviour. Was there a specific intention behind this design?

[seans887]

Just echoing that this behavior seems unintuitive and makes it difficult to parse and display errors. Hoping there is an alternative or "escape hatch" planned.

[rodgetech]

Any updates on this?

[jasonkuhrt]

IIUC this issue is made obsolete by https://github.com/jasonkuhrt/graphql-request/issues/509.