Right now, some errors get sent to the client, which include details that may not be desirable to reveal publicly. Need a way to capture errors and handle them outside of this library.
+1 We probably could do this by checking whether the error implements certain interface and use it instead of the string representation.
For returned errors I see this as a simple solution:
if err := [...] ; err != nil {
myErrorHandler(err)
return nil, errors.New("something went wrong, but I won't tell you what")
}
For panics I think that in the future they will not include the panic's message any more, but simply say "an internal error occurred". However, I can only do that after finishing all the necessary error reporting for bad queries.
Is there something preventing errors from being returned as part of Schema.Exec? Then they could be dealt with as part of the normal flow inside a request.
What you suggest I think would work, but at a glance doesn't appear to be the ideal solution.
Returning the errors like this is according to the spec, see https://facebook.github.io/graphql/#sec-Errors. If you really want to hide all errors from the client, couldn't you just not send the Errors field to the client after calling Schema.Exec, for example by setting it to nil?
Good points, and I think these are a product of me not understanding the spec well yet, as well as not knowing the details of your library. I see now I can access those errors via the returned response.
The original concern I had was that an error message was being sent to the client that included information about the source code that I don't think should be sent. I don't recall whether this was an error with the marshal part, or from the schema.Exec, so I'll need to keep an eye open for if I run across it again.
I'd like errors to be sent to the client as per the spec, but not containing details about source code. What do you think? I realise this will be much more helpful if I can provide you with an example.
Yes, please provide an example. Maybe it was related to a panic. I'm closing this issue until we can specify it further.
Most helpful comment
For returned errors I see this as a simple solution:
For panics I think that in the future they will not include the panic's message any more, but simply say "an internal error occurred". However, I can only do that after finishing all the necessary error reporting for bad queries.