Description
Q | A |
---|---|
Bug report? | not sure |
Feature request? | not sure |
BC Break report? | not sure |
RFC? | no |
Version/Branch | 1.6.0 |
If I understand the error handling correctly based on Overblog\GraphQLBundle\Error\ErrorHandler
, we have:
- and error converter to completely transform an error object into another if desired
- the result
extensions
that is populated by formatted errors - if
rethrow_internal_exceptions = true
, the formatting may be skipped and instead an error, if not aGraphQL\Error\UserError | Overblog\GraphQLBundle\Error\UserWarning
I am wondering a bit of the usage of rethrow_internal_exceptions
as I assume on a production system you would not want to return a non-GraphQL response to a GraphQL query, so I was under the impression this was either for exception specific use cases or for dev/tests, as it is easier to deal with the original exception.
However, based on the implementation of the error handler, this cannot be because as soon as you throw an exception, if it is not a UserError
or UserWarning
, with rethrow_internal_exceptions = true
, it will rethrow. As a result, something like a validation error (a Overblog\GraphQLBundle\Validator\Exception\ArgumentsValidationException
) will bubble up instead of being formatted nicely.
Wouldn't it make more sense to consider as "internal" exceptions that are not ClientAware
or ClientAware
with isClientSafe = false
instead?