graphql-php/docs/error-handling.md

194 lines
5.6 KiB
Markdown
Raw Permalink Normal View History

# Errors in GraphQL
2017-08-20 18:10:37 +03:00
Query execution process never throws exceptions. Instead, all errors are caught and collected.
After execution, they are available in **$errors** prop of
[`GraphQL\Executor\ExecutionResult`](reference.md#graphqlexecutorexecutionresult).
2017-08-20 18:10:37 +03:00
When the result is converted to a serializable array using its **toArray()** method, all errors are
converted to arrays as well using default error formatting (see below).
Alternatively, you can apply [custom error filtering and formatting](#custom-error-handling-and-formatting)
2017-08-16 22:17:01 +03:00
for your specific requirements.
# Default Error formatting
2017-08-20 18:10:37 +03:00
By default, each error entry is converted to an associative array with following structure:
```php
2017-08-20 18:10:37 +03:00
<?php
[
2017-08-16 22:17:01 +03:00
'message' => 'Error message',
'category' => 'graphql',
'locations' => [
['line' => 1, 'column' => 2]
],
2017-08-20 18:10:37 +03:00
'path' => [
2017-08-16 22:17:01 +03:00
'listField',
0,
'fieldWithException'
]
2017-08-20 18:10:37 +03:00
];
```
2017-08-20 18:10:37 +03:00
Entry at key **locations** points to a character in query string which caused the error.
In some cases (like deep fragment fields) locations will include several entries to track down
the path to field with the error in query.
2017-08-16 22:17:01 +03:00
2017-08-20 18:10:37 +03:00
Entry at key **path** exists only for errors caused by exceptions thrown in resolvers.
It contains a path from the very root field to actual field value producing an error
2017-08-16 22:17:01 +03:00
(including indexes for list types and field names for composite types).
**Internal errors**
2017-08-20 18:10:37 +03:00
As of version **0.10.0**, all exceptions thrown in resolvers are reported with generic message **"Internal server error"**.
2017-08-16 22:17:01 +03:00
This is done to avoid information leak in production environments (e.g. database connection errors, file access errors, etc).
2017-08-20 18:10:37 +03:00
Only exceptions implementing interface [`GraphQL\Error\ClientAware`](reference.md#graphqlerrorclientaware) and claiming themselves as **safe** will
be reported with a full error message.
2017-08-16 22:17:01 +03:00
For example:
```php
2017-08-20 18:10:37 +03:00
<?php
2017-08-16 22:17:01 +03:00
use GraphQL\Error\ClientAware;
class MySafeException extends \Exception implements ClientAware
{
public function isClientSafe()
{
return true;
}
public function getCategory()
{
return 'businessLogic';
}
}
```
2017-08-20 18:10:37 +03:00
When such exception is thrown it will be reported with a full error message:
```php
2017-08-20 18:10:37 +03:00
<?php
[
2017-08-16 22:17:01 +03:00
'message' => 'My reported error',
'category' => 'businessLogic',
'locations' => [
['line' => 10, 'column' => 2]
],
2017-08-20 18:10:37 +03:00
'path' => [
2017-08-16 22:17:01 +03:00
'path',
'to',
'fieldWithException'
]
2017-08-20 18:10:37 +03:00
];
```
2017-08-16 22:17:01 +03:00
To change default **"Internal server error"** message to something else, use:
```
GraphQL\Error\FormattedError::setInternalErrorMessage("Unexpected error");
```
# Debugging tools
2017-08-16 22:17:01 +03:00
During development or debugging use `$result->toArray(true)` to add **debugMessage** key to
each formatted error entry. If you also want to add exception trace - pass flags instead:
```
2017-08-17 16:35:58 +03:00
use GraphQL\Error\Debug;
$debug = Debug::INCLUDE_DEBUG_MESSAGE | Debug::INCLUDE_TRACE;
2017-08-16 22:17:01 +03:00
$result = GraphQL::executeQuery(/*args*/)->toArray($debug);
```
2017-08-16 22:17:01 +03:00
This will make each error entry to look like this:
```php
2017-08-20 18:10:37 +03:00
<?php
2017-08-16 22:17:01 +03:00
[
'debugMessage' => 'Actual exception message',
2017-08-17 16:35:58 +03:00
'message' => 'Internal server error',
2017-08-16 22:17:01 +03:00
'category' => 'internal',
'locations' => [
['line' => 10, 'column' => 2]
],
2017-08-20 18:10:37 +03:00
'path' => [
2017-08-16 22:17:01 +03:00
'listField',
0,
'fieldWithException'
],
'trace' => [
/* Formatted original exception trace */
]
2017-08-20 18:10:37 +03:00
];
```
If you prefer the first resolver exception to be re-thrown, use following flags:
```php
2017-08-20 18:10:37 +03:00
<?php
use GraphQL\GraphQL;
2017-08-17 16:35:58 +03:00
use GraphQL\Error\Debug;
$debug = Debug::INCLUDE_DEBUG_MESSAGE | Debug::RETHROW_INTERNAL_EXCEPTIONS;
// Following will throw if there was an exception in resolver during execution:
$result = GraphQL::executeQuery(/*args*/)->toArray($debug);
```
If you only want to re-throw Exceptions that are not marked as safe through the `ClientAware` interface, use
the flag `Debug::RETHROW_UNSAFE_EXCEPTIONS`.
2017-08-16 22:17:01 +03:00
# Custom Error Handling and Formatting
It is possible to define custom **formatter** and **handler** for result errors.
2017-08-20 18:10:37 +03:00
**Formatter** is responsible for converting instances of [`GraphQL\Error\Error`](reference.md#graphqlerrorerror)
to an array. **Handler** is useful for error filtering and logging.
2017-08-20 18:10:37 +03:00
For example, these are default formatter and handler:
2017-08-16 22:17:01 +03:00
```php
2017-08-20 18:10:37 +03:00
<?php
use GraphQL\GraphQL;
2017-08-16 22:17:01 +03:00
use GraphQL\Error\Error;
use GraphQL\Error\FormattedError;
2017-08-16 22:17:01 +03:00
$myErrorFormatter = function(Error $error) {
return FormattedError::createFromException($error);
};
2017-08-16 22:17:01 +03:00
$myErrorHandler = function(array $errors, callable $formatter) {
return array_map($formatter, $errors);
};
$result = GraphQL::executeQuery(/* $args */)
->setErrorFormatter($myErrorFormatter)
2017-10-16 19:05:43 +03:00
->setErrorsHandler($myErrorHandler)
->toArray();
```
2017-08-20 18:10:37 +03:00
Note that when you pass [debug flags](#debugging-tools) to **toArray()** your custom formatter will still be
2017-08-17 16:35:58 +03:00
decorated with same debugging information mentioned above.
2017-08-16 22:17:01 +03:00
# Schema Errors
2016-11-10 21:00:55 +03:00
So far we only covered errors which occur during query execution process. But schema definition can
2017-08-16 22:17:01 +03:00
also throw `GraphQL\Error\InvariantViolation` if there is an error in one of type definitions.
Usually such errors mean that there is some logical error in your schema and it is the only case
when it makes sense to return `500` error code for GraphQL endpoint:
```php
2017-08-20 18:10:37 +03:00
<?php
use GraphQL\GraphQL;
use GraphQL\Type\Schema;
use GraphQL\Error\FormattedError;
try {
$schema = new Schema([
// ...
]);
2017-08-16 22:17:01 +03:00
$body = GraphQL::executeQuery($schema, $query);
2016-11-25 14:07:51 +03:00
$status = 200;
} catch(\Exception $e) {
2017-08-20 18:10:37 +03:00
$body = [
'errors' => [FormattedError::createFromException($e)]
];
2016-11-25 14:07:51 +03:00
$status = 500;
}
2016-11-25 14:07:51 +03:00
header('Content-Type: application/json', true, $status);
echo json_encode($body);
```