Move error handling closer to the spec

haskell-graphql / graphql-api

Write type-safe GraphQL services in Haskell

BSD 3-Clause "New" or "Revised" License

406 stars 35 forks source link

Move error handling closer to the spec #43

Closed teh closed 7 years ago

teh commented 7 years ago

The main change here is that instead of an Either we now have a Result which accumulates errors and values at the same time.

This is still a draft but wanted to get your opinion early
I'm not super happy with ResolveFieldResult but not sure ATM how to phrase better (other than maybe a separate data type)
MonadIO & throw are gone
Error accumulation needs a nicer representation but a I can't tell from the description what errors for specific fields should look like.

jml commented 7 years ago

Error accumulation needs a nicer representation but a I can't tell from the description what errors for specific fields should look like.

This part is already encoded in GraphQL/Internal/Output.hs. There isn't a way of encoding errors for specific fields, there's just one top-level errors key that has all the errors.

We need just need a structured type (or types, I guess) that we can convert to GraphQL.Internal.Output.Error when we want to serialise it.

jml commented 7 years ago

Just occurred to me that this isn't miles off the Writer monad.

teh commented 7 years ago

Agree could technically be a WriterT but IMO the direct collection or errors and results is more readable.

jml commented 7 years ago

Agree could technically be a WriterT but IMO the direct collection or errors and results is more readable.

Did you try this and discover that you preferred the existing way, or is this a guess? If the latter, would you mind if I made an attempt at some later point?