You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
desc: Rescuing application errors from field resolvers
8
+
index: 3
9
+
---
10
+
11
+
You can configure your schema to rescue application errors during field resolution. Errors during batch loading will also be rescued.
12
+
13
+
__Note:__ This feature is for class-based schemas using the {% internal_link "interpreter runtime", "/queries/interpreter" %} only. For `.define`-based schemas, use [exAspArk/graphql-errors](https://github.com/exaspark/graphql-errors) instead.
14
+
15
+
Thanks to [`@exAspArk`] for the [`graphql-errors`](https://github.com/exAspArk/graphql-errors) gem which inspired this behavior and [`@thiago-sydow`](https://github.com/thiago-sydow) who [suggested](https://github.com/rmosolgo/graphql-ruby/issues/2139#issuecomment-524913594) and implementation like this.
16
+
17
+
## Setup
18
+
19
+
Add error handling to your schema with `use GraphQL::Execution::Errors`. (This will be the default in a future graphql-ruby version.)
20
+
21
+
```ruby
22
+
classMySchema < GraphQL::Schema
23
+
# Use the new runtime & analyzers:
24
+
use GraphQL::Execution::Interpreter
25
+
use GraphQL::Analysis::AST
26
+
# Also use the new error handling:
27
+
use GraphQL::Execution::Errors
28
+
end
29
+
```
30
+
31
+
## Add error handlers
32
+
33
+
Handlers are added with `rescue_from` configurations in the schema:
34
+
35
+
```ruby
36
+
classMySchema < GraphQL::Schema
37
+
# ...
38
+
39
+
rescue_from(ActiveRecord::NotFound) do |err, obj, args, ctx, field|
40
+
# Raise a graphql-friendly error with a custom message
41
+
raiseGraphQL::ExecutionError, "#{field.type.unwrap.graphql_name} not found"
42
+
end
43
+
44
+
rescue_from(SearchIndex::UnavailableError) do |err, obj, args, ctx, field|
45
+
# Log the error
46
+
Bugsnag.notify(err)
47
+
# replace it with nil
48
+
nil
49
+
end
50
+
end
51
+
```
52
+
53
+
The handler is called with several arguments:
54
+
55
+
-__`err`__ is the error that was raised during field execution, then rescued
56
+
-__`obj`__ is the object which was having a field resolved against it
57
+
-__`args`__ is the the Hash of arguments passed to the resolver
58
+
-__`ctx`__ is the query context
59
+
-__`field`__ is the {{ "GraphQL::Schema::Field" | api_doc }} instance for the field where the error was rescued
60
+
61
+
Inside the handler, you can:
62
+
63
+
- Raise a GraphQL-friendly {{ "GraphQL::ExecutionError" | api_doc }} to return to the user
64
+
- Re-raise the given `err` to crash the query and halt execution. (The error will propagate to your application, eg, the controller.)
65
+
- Report some metrics from the error, if applicable
66
+
- Return a new value to be used for the error case (if not raising another error)
Copy file name to clipboardExpand all lines: guides/errors/overview.md
+4Lines changed: 4 additions & 0 deletions
Original file line number
Diff line number
Diff line change
@@ -46,6 +46,10 @@ The GraphQL specification provides for a top-level `"errors"` key which may incl
46
46
47
47
In your own schema, you can add to the `"errors"` key by raising `GraphQL::ExecutionError` (or subclasses of it) in your code. Read more in the {% internal_link "Execution Errors guide", "/errors/execution_errors" %}.
48
48
49
+
## Handled Errors
50
+
51
+
A schema can be configured to handle certain errors during field execution with handlers that you give it, using `rescue_from`. Read more in the {% internal_link "Error Handling guide", "/errors/error_handling" %}.
52
+
49
53
## Unhandled Errors (Crashes)
50
54
51
55
When a `raise`d error is not `rescue`d, the GraphQL query crashes entirely and the surrounding code (like a Rails controller) must handle the exception.
0 commit comments