Support GraphQL errors as in GraphQL spec

[adelcasse]

Following issue #148, what about something like that that could avoid introducing a breaking change and still handle valid GraphQL errors as in official GraphQL specification ?

I've implemented it on HTTP only for the moment (as a proof of concept) and it could definitely be improved by doing things similar to path errors ...

If it's something interesting for you, I'll pursue on that direction.

[coveralls]

Pull Request Test Coverage Report for Build 901

• 4 of 32 (12.5%) changed or added relevant lines in 2 files are covered.
• 2 unchanged lines in 1 file lost coverage.
• Overall coverage decreased (-0.3%) to 63.098%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
graphql/http.go	4	18	22.22%
graphql/server.go	0	14	0.0%
<!--	Total:	4	32

Files with Coverage Reduction	New Missed Lines	%
graphql/schemabuilder/reflect.go	2	71.81%
<!--	Total:	2

Totals
Change from base Build 888:	-0.3%
Covered Lines:	3112
Relevant Lines:	4932

---

💛 - Coveralls

[ccbrown]

Setting the location and path shouldn't be the library consumer's responsibility; it should be the library's. Imo there should simply be a flag on the schema that enables spec-compliant errors. And extensions should be facilitated via interface rather than concrete error type.

[squk]

Is this going anywhwere? Or has an alternative PR been made/merged? This has been open since Aug 2018.

[gobaldia]

@CodeBrew28 I know this has been inactive for a while, but I'd like to know if you're considering to support errors as in GraphQL spec. Thunder is a great library, but it's a pity to manage errors in the current way.

[adelcasse]

I don't think they will answer. In https://github.com/samsarahq/thunder/issues/148 they gave a first answer (which pointed me to a private repository I coudn't read) and then, instead of explaining more, deleted this answer and never got back to me. (They could just have said "no we don't want to change that")