New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open ReferenceExecutor for extending #801
Conversation
I highly recommend you to not change that behaviour and instead read the GraphQL specification thoroughly and try to understand why error handling in GraphQL works in this particular way: http://spec.graphql.org/draft/#sec-Execution. In short: GraphQL queries are complex and may contain many fields. An error in one field should not abort the entire query. Regardless of that, I generally think that opening up library code for extensiblity is a good thing. We should apply that consistently throughout the class though. |
I make it not for error in fields. For example I have query: class Status {
/**
* @param null $_
* @param array<string, mixed> $args
*/
public function __invoke($_, array $args) {
throw new \Exception('dcdcd');
} With default {
"errors": [
{
"debugMessage": "dcdcd",
"message": "Internal server error",
"extensions": {
"category": "internal"
},
"locations": [
{
"line": 2,
"column": 3
}
],
"path": [
"status"
],
"trace": [
{ I don't know what the format is, this is not my error handler. I want to turn it off. But with {
"errors": [
{
"id": "e84880e179a64be98d1f421b83252f23",
"status": 500,
"title": "Internal Server Error",
"detail": "An error has occurred and this resource cannot be displayed."
}
]
} This is my application's error handler. I need it. |
Please read the spec. Your format is not compliant. |
Even Facebook and Instagram display errors in his own format without compliant the spec. |
Standard tools are not going to work as well when deviating from the specification. Anyways, concerning this PR: every instance of |
Okay, I change every instance of A little about my case. I am using only a small part of the graphQL capabilities for one of the projects. First of all, the schema as a contract and documentation for developers. All my graphQL requests are stored in the repository, they are verified, tested and approved. The server is under authorization. Requests to it only from trusted services. All queries always return only 1 or 0 entities by ID. The entity either returns completely or does not return. There are no other types of requests and are not planned. GraphQL is no more than 5% of the code and traffic from the entire volume of the projects. It is more important to have the same error handling system for all projects and components. During the 2 years of the project's existence, a graphQL spec error format has never been required and has not been useful. |
I suppose this line stay as private.
|
…ldValueOrError method
@spawnia Thanks. It would be very nice to make a release. |
(cherry picked from commit c19cd7c)
Case: need overwrite
resolveFieldValueOrError
withouttry catch
block and handle exception in my own error handler from application. Without this patch, it is impossible to override this behavior.