2020-04-15 03:15:30 +00:00
# Error extensions
2020-05-11 12:22:20 +00:00
To quote the [graphql-spec ](https://spec.graphql.org/June2018/#example-fce18 ):
> GraphQL services may provide an additional entry to errors with key extensions.
2020-09-01 05:47:22 +00:00
> This entry, if set, must have a map as its value. This entry is reserved for implementer to add
2020-05-11 12:22:20 +00:00
> additional information to errors however they see fit, and there are no additional restrictions on
> its contents.
## Example
I would recommend on checking out this [async-graphql example ](https://github.com/async-graphql/examples/blob/master/actix-web/error-extensions/src/main.rs ) as a quickstart.
## General Concept
Rework errors
This completely overhauls the error system used in async-graphql.
- `Error` has been renamed to `ServerError` and `FieldError` has been
renamed to just `Error`. This is because `FieldError` is by far the most
common error that users will have to use so it makes sense to use the
most obvious error name. Also, the current name didn't make sense as it
was used for things other than field errors, such as the data callback
for websockets.
- `ServerError` has been made completely opaque. Before it was an enum
of all the possible errors, but now it just contains an error message,
the locations, the path and extensions. It is a shame that we lose
information, it makes more sense as _conceptually_ GraphQL does not
provide that information. It also frees us to change the internals of
async-graphql a lot more.
- The path of errors is no longer an opaque JSON value but a regular
type, `Vec<PathSegment>`. The type duplication of `PathSegment` and
`QueryPathSegment` is unfortunate, I plan to work on this in the future.
- Now that `ServerError` is opaque, `RuleError` has been removed from
the public API, making it simpler.
- Additionally `QueryError` has been completely removed. Instead the
error messages are constructed ad-hoc; I took care to never repeat an
error message.
- Instead of constructing field-not-found errors inside the
implementations of field resolvers they now return `Option`s, where a
`None` value is representative of the field not being found.
- As an unfortunate consequence of the last change, self-referential
types based on the output of a subscription resolver can no longer be
created. This does not mean anything for users, but causes lifetime
issues in the implementation of merged objects. I fixed it with a bit of
a hack, but this'll have to be looked into further.
- `InputValueError` now has a generic parameter - it's kind of weird but
it's necessary for ergonomics. It also improves error messages.
- The `ErrorExtensions` trait has been removed. I didn't think the
`extend` method was necessary since `From` impls exist. But the
ergonomics are still there with a new trait `ExtendError`, which
is implemented for both errors and results.
- `Response` now supports serializing multiple errors. This allows for
nice things like having multiple validation errors not be awkwardly
shoved into a single error.
- When an error occurs in execution, data is sent as `null`. This is
slightly more compliant with the spec but the algorithm described in
<https://spec.graphql.org/June2018/#sec-Errors-and-Non-Nullability> has
yet to be implemented.
2020-09-29 19:06:44 +00:00
In `async-graphql` all user-facing errors are cast to the `Error` type which by default provides
2020-10-10 02:32:43 +00:00
the error message exposed by `std::fmt::Display` . However, `Error` actually provides an additional information that can extend the error.
2020-05-11 12:22:20 +00:00
2020-09-01 05:47:22 +00:00
A resolver looks like this:
2020-05-11 12:22:20 +00:00
```rust
2022-06-02 21:32:12 +00:00
# extern crate async_graphql;
# use async_graphql::*;
# struct Query;
# #[Object]
# impl Query {
2020-10-10 02:32:43 +00:00
async fn parse_with_extensions(& self) -> Result< i32 , Error > {
Err(Error::new("MyMessage").extend_with(|_, e| e.set("details", "CAN_NOT_FETCH")))
}
2022-06-02 21:32:12 +00:00
# }
2020-05-11 12:22:20 +00:00
```
may then return a response like this:
```json
{
"errors": [
{
"message": "MyMessage",
"locations": [ ... ],
"path": [ ... ],
"extensions": {
"details": "CAN_NOT_FETCH",
}
}
]
}
```
## ErrorExtensions
Rework errors
This completely overhauls the error system used in async-graphql.
- `Error` has been renamed to `ServerError` and `FieldError` has been
renamed to just `Error`. This is because `FieldError` is by far the most
common error that users will have to use so it makes sense to use the
most obvious error name. Also, the current name didn't make sense as it
was used for things other than field errors, such as the data callback
for websockets.
- `ServerError` has been made completely opaque. Before it was an enum
of all the possible errors, but now it just contains an error message,
the locations, the path and extensions. It is a shame that we lose
information, it makes more sense as _conceptually_ GraphQL does not
provide that information. It also frees us to change the internals of
async-graphql a lot more.
- The path of errors is no longer an opaque JSON value but a regular
type, `Vec<PathSegment>`. The type duplication of `PathSegment` and
`QueryPathSegment` is unfortunate, I plan to work on this in the future.
- Now that `ServerError` is opaque, `RuleError` has been removed from
the public API, making it simpler.
- Additionally `QueryError` has been completely removed. Instead the
error messages are constructed ad-hoc; I took care to never repeat an
error message.
- Instead of constructing field-not-found errors inside the
implementations of field resolvers they now return `Option`s, where a
`None` value is representative of the field not being found.
- As an unfortunate consequence of the last change, self-referential
types based on the output of a subscription resolver can no longer be
created. This does not mean anything for users, but causes lifetime
issues in the implementation of merged objects. I fixed it with a bit of
a hack, but this'll have to be looked into further.
- `InputValueError` now has a generic parameter - it's kind of weird but
it's necessary for ergonomics. It also improves error messages.
- The `ErrorExtensions` trait has been removed. I didn't think the
`extend` method was necessary since `From` impls exist. But the
ergonomics are still there with a new trait `ExtendError`, which
is implemented for both errors and results.
- `Response` now supports serializing multiple errors. This allows for
nice things like having multiple validation errors not be awkwardly
shoved into a single error.
- When an error occurs in execution, data is sent as `null`. This is
slightly more compliant with the spec but the algorithm described in
<https://spec.graphql.org/June2018/#sec-Errors-and-Non-Nullability> has
yet to be implemented.
2020-09-29 19:06:44 +00:00
Constructing new `Error` s by hand quickly becomes tedious. That is why `async-graphql` provides
two convenience traits for casting your errors to the appropriate `Error` with
2020-05-11 12:22:20 +00:00
extensions.
2020-05-12 09:05:25 +00:00
The easiest way to provide extensions to any error is by calling `extend_with` on the error.
Rework errors
This completely overhauls the error system used in async-graphql.
- `Error` has been renamed to `ServerError` and `FieldError` has been
renamed to just `Error`. This is because `FieldError` is by far the most
common error that users will have to use so it makes sense to use the
most obvious error name. Also, the current name didn't make sense as it
was used for things other than field errors, such as the data callback
for websockets.
- `ServerError` has been made completely opaque. Before it was an enum
of all the possible errors, but now it just contains an error message,
the locations, the path and extensions. It is a shame that we lose
information, it makes more sense as _conceptually_ GraphQL does not
provide that information. It also frees us to change the internals of
async-graphql a lot more.
- The path of errors is no longer an opaque JSON value but a regular
type, `Vec<PathSegment>`. The type duplication of `PathSegment` and
`QueryPathSegment` is unfortunate, I plan to work on this in the future.
- Now that `ServerError` is opaque, `RuleError` has been removed from
the public API, making it simpler.
- Additionally `QueryError` has been completely removed. Instead the
error messages are constructed ad-hoc; I took care to never repeat an
error message.
- Instead of constructing field-not-found errors inside the
implementations of field resolvers they now return `Option`s, where a
`None` value is representative of the field not being found.
- As an unfortunate consequence of the last change, self-referential
types based on the output of a subscription resolver can no longer be
created. This does not mean anything for users, but causes lifetime
issues in the implementation of merged objects. I fixed it with a bit of
a hack, but this'll have to be looked into further.
- `InputValueError` now has a generic parameter - it's kind of weird but
it's necessary for ergonomics. It also improves error messages.
- The `ErrorExtensions` trait has been removed. I didn't think the
`extend` method was necessary since `From` impls exist. But the
ergonomics are still there with a new trait `ExtendError`, which
is implemented for both errors and results.
- `Response` now supports serializing multiple errors. This allows for
nice things like having multiple validation errors not be awkwardly
shoved into a single error.
- When an error occurs in execution, data is sent as `null`. This is
slightly more compliant with the spec but the algorithm described in
<https://spec.graphql.org/June2018/#sec-Errors-and-Non-Nullability> has
yet to be implemented.
2020-09-29 19:06:44 +00:00
This will on the fly convert any error into a `Error` with the given extension.
2020-05-11 12:22:20 +00:00
```rust
2022-06-02 21:32:12 +00:00
# extern crate async_graphql;
# use async_graphql::*;
# struct Query;
2020-05-11 12:22:20 +00:00
use std::num::ParseIntError;
2022-06-02 21:32:12 +00:00
# #[Object]
# impl Query {
Rework errors
This completely overhauls the error system used in async-graphql.
- `Error` has been renamed to `ServerError` and `FieldError` has been
renamed to just `Error`. This is because `FieldError` is by far the most
common error that users will have to use so it makes sense to use the
most obvious error name. Also, the current name didn't make sense as it
was used for things other than field errors, such as the data callback
for websockets.
- `ServerError` has been made completely opaque. Before it was an enum
of all the possible errors, but now it just contains an error message,
the locations, the path and extensions. It is a shame that we lose
information, it makes more sense as _conceptually_ GraphQL does not
provide that information. It also frees us to change the internals of
async-graphql a lot more.
- The path of errors is no longer an opaque JSON value but a regular
type, `Vec<PathSegment>`. The type duplication of `PathSegment` and
`QueryPathSegment` is unfortunate, I plan to work on this in the future.
- Now that `ServerError` is opaque, `RuleError` has been removed from
the public API, making it simpler.
- Additionally `QueryError` has been completely removed. Instead the
error messages are constructed ad-hoc; I took care to never repeat an
error message.
- Instead of constructing field-not-found errors inside the
implementations of field resolvers they now return `Option`s, where a
`None` value is representative of the field not being found.
- As an unfortunate consequence of the last change, self-referential
types based on the output of a subscription resolver can no longer be
created. This does not mean anything for users, but causes lifetime
issues in the implementation of merged objects. I fixed it with a bit of
a hack, but this'll have to be looked into further.
- `InputValueError` now has a generic parameter - it's kind of weird but
it's necessary for ergonomics. It also improves error messages.
- The `ErrorExtensions` trait has been removed. I didn't think the
`extend` method was necessary since `From` impls exist. But the
ergonomics are still there with a new trait `ExtendError`, which
is implemented for both errors and results.
- `Response` now supports serializing multiple errors. This allows for
nice things like having multiple validation errors not be awkwardly
shoved into a single error.
- When an error occurs in execution, data is sent as `null`. This is
slightly more compliant with the spec but the algorithm described in
<https://spec.graphql.org/June2018/#sec-Errors-and-Non-Nullability> has
yet to be implemented.
2020-09-29 19:06:44 +00:00
async fn parse_with_extensions(& self) -> Result< i32 > {
2020-05-11 12:22:20 +00:00
Ok("234a"
.parse()
2020-10-10 02:32:43 +00:00
.map_err(|err: ParseIntError| err.extend_with(|_err, e| e.set("code", 404)))?)
}
2022-06-02 21:32:12 +00:00
# }
2020-05-11 12:22:20 +00:00
```
### Implementing ErrorExtensions for custom errors.
If you find yourself attaching extensions to your errors all over the place you might want to consider
implementing the trait on your custom error type directly.
```rust
2022-06-02 21:32:12 +00:00
# extern crate async_graphql;
# extern crate thiserror;
# use async_graphql::*;
#[derive(Debug, thiserror::Error)]
2020-05-11 12:22:20 +00:00
pub enum MyError {
#[error("Could not find resource")]
NotFound,
#[error("ServerError")]
ServerError(String),
#[error("No Extensions")]
ErrorWithoutExtensions,
}
impl ErrorExtensions for MyError {
// lets define our base extensions
Rework errors
This completely overhauls the error system used in async-graphql.
- `Error` has been renamed to `ServerError` and `FieldError` has been
renamed to just `Error`. This is because `FieldError` is by far the most
common error that users will have to use so it makes sense to use the
most obvious error name. Also, the current name didn't make sense as it
was used for things other than field errors, such as the data callback
for websockets.
- `ServerError` has been made completely opaque. Before it was an enum
of all the possible errors, but now it just contains an error message,
the locations, the path and extensions. It is a shame that we lose
information, it makes more sense as _conceptually_ GraphQL does not
provide that information. It also frees us to change the internals of
async-graphql a lot more.
- The path of errors is no longer an opaque JSON value but a regular
type, `Vec<PathSegment>`. The type duplication of `PathSegment` and
`QueryPathSegment` is unfortunate, I plan to work on this in the future.
- Now that `ServerError` is opaque, `RuleError` has been removed from
the public API, making it simpler.
- Additionally `QueryError` has been completely removed. Instead the
error messages are constructed ad-hoc; I took care to never repeat an
error message.
- Instead of constructing field-not-found errors inside the
implementations of field resolvers they now return `Option`s, where a
`None` value is representative of the field not being found.
- As an unfortunate consequence of the last change, self-referential
types based on the output of a subscription resolver can no longer be
created. This does not mean anything for users, but causes lifetime
issues in the implementation of merged objects. I fixed it with a bit of
a hack, but this'll have to be looked into further.
- `InputValueError` now has a generic parameter - it's kind of weird but
it's necessary for ergonomics. It also improves error messages.
- The `ErrorExtensions` trait has been removed. I didn't think the
`extend` method was necessary since `From` impls exist. But the
ergonomics are still there with a new trait `ExtendError`, which
is implemented for both errors and results.
- `Response` now supports serializing multiple errors. This allows for
nice things like having multiple validation errors not be awkwardly
shoved into a single error.
- When an error occurs in execution, data is sent as `null`. This is
slightly more compliant with the spec but the algorithm described in
<https://spec.graphql.org/June2018/#sec-Errors-and-Non-Nullability> has
yet to be implemented.
2020-09-29 19:06:44 +00:00
fn extend(& self) -> Error {
2020-10-10 02:32:43 +00:00
Error::new(format!("{}", self)).extend_with(|err, e|
2020-10-02 07:34:20 +00:00
match self {
2020-10-10 02:32:43 +00:00
MyError::NotFound => e.set("code", "NOT_FOUND"),
2022-06-02 21:32:12 +00:00
MyError::ServerError(reason) => e.set("reason", reason.clone()),
2020-10-10 02:32:43 +00:00
MyError::ErrorWithoutExtensions => {}
2020-10-02 07:34:20 +00:00
})
2020-05-11 12:22:20 +00:00
}
}
```
This way you only need to call `extend` on your error to deliver the error message alongside the provided extensions.
Or further extend your error through `extend_with` .
```rust
2022-06-02 21:32:12 +00:00
# extern crate async_graphql;
# extern crate thiserror;
# use async_graphql::*;
# #[derive(Debug, thiserror::Error)]
# pub enum MyError {
# #[error("Could not find resource")]
# NotFound,
#
# #[error("ServerError")]
# ServerError(String),
#
# #[error("No Extensions")]
# ErrorWithoutExtensions,
# }
# struct Query;
# #[Object]
# impl Query {
Rework errors
This completely overhauls the error system used in async-graphql.
- `Error` has been renamed to `ServerError` and `FieldError` has been
renamed to just `Error`. This is because `FieldError` is by far the most
common error that users will have to use so it makes sense to use the
most obvious error name. Also, the current name didn't make sense as it
was used for things other than field errors, such as the data callback
for websockets.
- `ServerError` has been made completely opaque. Before it was an enum
of all the possible errors, but now it just contains an error message,
the locations, the path and extensions. It is a shame that we lose
information, it makes more sense as _conceptually_ GraphQL does not
provide that information. It also frees us to change the internals of
async-graphql a lot more.
- The path of errors is no longer an opaque JSON value but a regular
type, `Vec<PathSegment>`. The type duplication of `PathSegment` and
`QueryPathSegment` is unfortunate, I plan to work on this in the future.
- Now that `ServerError` is opaque, `RuleError` has been removed from
the public API, making it simpler.
- Additionally `QueryError` has been completely removed. Instead the
error messages are constructed ad-hoc; I took care to never repeat an
error message.
- Instead of constructing field-not-found errors inside the
implementations of field resolvers they now return `Option`s, where a
`None` value is representative of the field not being found.
- As an unfortunate consequence of the last change, self-referential
types based on the output of a subscription resolver can no longer be
created. This does not mean anything for users, but causes lifetime
issues in the implementation of merged objects. I fixed it with a bit of
a hack, but this'll have to be looked into further.
- `InputValueError` now has a generic parameter - it's kind of weird but
it's necessary for ergonomics. It also improves error messages.
- The `ErrorExtensions` trait has been removed. I didn't think the
`extend` method was necessary since `From` impls exist. But the
ergonomics are still there with a new trait `ExtendError`, which
is implemented for both errors and results.
- `Response` now supports serializing multiple errors. This allows for
nice things like having multiple validation errors not be awkwardly
shoved into a single error.
- When an error occurs in execution, data is sent as `null`. This is
slightly more compliant with the spec but the algorithm described in
<https://spec.graphql.org/June2018/#sec-Errors-and-Non-Nullability> has
yet to be implemented.
2020-09-29 19:06:44 +00:00
async fn parse_with_extensions_result(& self) -> Result< i32 > {
2020-05-11 12:22:20 +00:00
// Err(MyError::NotFound.extend())
// OR
2020-10-10 02:32:43 +00:00
Err(MyError::NotFound.extend_with(|_, e| e.set("on_the_fly", "some_more_info")))
2020-05-11 12:22:20 +00:00
}
2022-06-02 21:32:12 +00:00
# }
2020-05-11 12:22:20 +00:00
```
```json
{
"errors": [
{
"message": "NotFound",
"locations": [ ... ],
"path": [ ... ],
"extensions": {
"code": "NOT_FOUND",
"on_the_fly": "some_more_info"
}
}
]
}
```
## ResultExt
This trait enables you to call `extend_err` directly on results. So the above code becomes less verbose.
2022-06-02 21:32:12 +00:00
```rust,ignore
# // @todo figure out why this example does not compile!
# extern crate async_graphql;
2020-05-11 12:22:20 +00:00
use async_graphql::*;
2022-06-02 21:32:12 +00:00
# struct Query;
# #[Object]
# impl Query {
Rework errors
This completely overhauls the error system used in async-graphql.
- `Error` has been renamed to `ServerError` and `FieldError` has been
renamed to just `Error`. This is because `FieldError` is by far the most
common error that users will have to use so it makes sense to use the
most obvious error name. Also, the current name didn't make sense as it
was used for things other than field errors, such as the data callback
for websockets.
- `ServerError` has been made completely opaque. Before it was an enum
of all the possible errors, but now it just contains an error message,
the locations, the path and extensions. It is a shame that we lose
information, it makes more sense as _conceptually_ GraphQL does not
provide that information. It also frees us to change the internals of
async-graphql a lot more.
- The path of errors is no longer an opaque JSON value but a regular
type, `Vec<PathSegment>`. The type duplication of `PathSegment` and
`QueryPathSegment` is unfortunate, I plan to work on this in the future.
- Now that `ServerError` is opaque, `RuleError` has been removed from
the public API, making it simpler.
- Additionally `QueryError` has been completely removed. Instead the
error messages are constructed ad-hoc; I took care to never repeat an
error message.
- Instead of constructing field-not-found errors inside the
implementations of field resolvers they now return `Option`s, where a
`None` value is representative of the field not being found.
- As an unfortunate consequence of the last change, self-referential
types based on the output of a subscription resolver can no longer be
created. This does not mean anything for users, but causes lifetime
issues in the implementation of merged objects. I fixed it with a bit of
a hack, but this'll have to be looked into further.
- `InputValueError` now has a generic parameter - it's kind of weird but
it's necessary for ergonomics. It also improves error messages.
- The `ErrorExtensions` trait has been removed. I didn't think the
`extend` method was necessary since `From` impls exist. But the
ergonomics are still there with a new trait `ExtendError`, which
is implemented for both errors and results.
- `Response` now supports serializing multiple errors. This allows for
nice things like having multiple validation errors not be awkwardly
shoved into a single error.
- When an error occurs in execution, data is sent as `null`. This is
slightly more compliant with the spec but the algorithm described in
<https://spec.graphql.org/June2018/#sec-Errors-and-Non-Nullability> has
yet to be implemented.
2020-09-29 19:06:44 +00:00
async fn parse_with_extensions(& self) -> Result< i32 > {
2020-05-11 12:22:20 +00:00
Ok("234a"
.parse()
2020-10-10 02:32:43 +00:00
.extend_err(|_, e| e.set("code", 404))?)
}
2022-06-02 21:32:12 +00:00
# }
2020-05-11 12:22:20 +00:00
```
### Chained extensions
Since `ErrorExtensions` and `ResultExt` are implemented for any type `&E where E: std::fmt::Display`
we can chain the extension together.
```rust
2022-06-02 21:32:12 +00:00
# extern crate async_graphql;
2020-05-11 12:22:20 +00:00
use async_graphql::*;
2022-06-02 21:32:12 +00:00
# struct Query;
# #[Object]
# impl Query {
Rework errors
This completely overhauls the error system used in async-graphql.
- `Error` has been renamed to `ServerError` and `FieldError` has been
renamed to just `Error`. This is because `FieldError` is by far the most
common error that users will have to use so it makes sense to use the
most obvious error name. Also, the current name didn't make sense as it
was used for things other than field errors, such as the data callback
for websockets.
- `ServerError` has been made completely opaque. Before it was an enum
of all the possible errors, but now it just contains an error message,
the locations, the path and extensions. It is a shame that we lose
information, it makes more sense as _conceptually_ GraphQL does not
provide that information. It also frees us to change the internals of
async-graphql a lot more.
- The path of errors is no longer an opaque JSON value but a regular
type, `Vec<PathSegment>`. The type duplication of `PathSegment` and
`QueryPathSegment` is unfortunate, I plan to work on this in the future.
- Now that `ServerError` is opaque, `RuleError` has been removed from
the public API, making it simpler.
- Additionally `QueryError` has been completely removed. Instead the
error messages are constructed ad-hoc; I took care to never repeat an
error message.
- Instead of constructing field-not-found errors inside the
implementations of field resolvers they now return `Option`s, where a
`None` value is representative of the field not being found.
- As an unfortunate consequence of the last change, self-referential
types based on the output of a subscription resolver can no longer be
created. This does not mean anything for users, but causes lifetime
issues in the implementation of merged objects. I fixed it with a bit of
a hack, but this'll have to be looked into further.
- `InputValueError` now has a generic parameter - it's kind of weird but
it's necessary for ergonomics. It also improves error messages.
- The `ErrorExtensions` trait has been removed. I didn't think the
`extend` method was necessary since `From` impls exist. But the
ergonomics are still there with a new trait `ExtendError`, which
is implemented for both errors and results.
- `Response` now supports serializing multiple errors. This allows for
nice things like having multiple validation errors not be awkwardly
shoved into a single error.
- When an error occurs in execution, data is sent as `null`. This is
slightly more compliant with the spec but the algorithm described in
<https://spec.graphql.org/June2018/#sec-Errors-and-Non-Nullability> has
yet to be implemented.
2020-09-29 19:06:44 +00:00
async fn parse_with_extensions(& self) -> Result< i32 > {
2020-05-12 09:05:25 +00:00
match "234a".parse() {
Ok(n) => Ok(n),
Err(e) => Err(e
2020-10-10 02:32:43 +00:00
.extend_with(|_, e| e.set("code", 404))
.extend_with(|_, e| e.set("details", "some more info.."))
2020-05-12 09:05:25 +00:00
// keys may also overwrite previous keys...
2020-10-10 02:32:43 +00:00
.extend_with(|_, e| e.set("code", 500))),
2020-05-12 09:05:25 +00:00
}
}
2022-06-02 21:32:12 +00:00
# }
2020-05-11 12:22:20 +00:00
```
Expected response:
```json
{
"errors": [
{
"message": "MyMessage",
"locations": [ ... ],
"path": [ ... ],
"extensions": {
"details": "some more info...",
"code": 500,
}
}
]
}
```
2020-05-12 09:05:25 +00:00
### Pitfalls
Rust does not provide stable trait specialization yet.
That is why `ErrorExtensions` is actually implemented for `&E where E: std::fmt::Display`
2020-09-01 05:47:22 +00:00
instead of `E: std::fmt::Display` . Some specialization is provided through
2020-05-12 09:05:25 +00:00
[Autoref-based stable specialization ](https://github.com/dtolnay/case-studies/blob/master/autoref-specialization/README.md ).
The disadvantage is that the below code does **NOT** compile:
```rust,ignore,does_not_compile
Rework errors
This completely overhauls the error system used in async-graphql.
- `Error` has been renamed to `ServerError` and `FieldError` has been
renamed to just `Error`. This is because `FieldError` is by far the most
common error that users will have to use so it makes sense to use the
most obvious error name. Also, the current name didn't make sense as it
was used for things other than field errors, such as the data callback
for websockets.
- `ServerError` has been made completely opaque. Before it was an enum
of all the possible errors, but now it just contains an error message,
the locations, the path and extensions. It is a shame that we lose
information, it makes more sense as _conceptually_ GraphQL does not
provide that information. It also frees us to change the internals of
async-graphql a lot more.
- The path of errors is no longer an opaque JSON value but a regular
type, `Vec<PathSegment>`. The type duplication of `PathSegment` and
`QueryPathSegment` is unfortunate, I plan to work on this in the future.
- Now that `ServerError` is opaque, `RuleError` has been removed from
the public API, making it simpler.
- Additionally `QueryError` has been completely removed. Instead the
error messages are constructed ad-hoc; I took care to never repeat an
error message.
- Instead of constructing field-not-found errors inside the
implementations of field resolvers they now return `Option`s, where a
`None` value is representative of the field not being found.
- As an unfortunate consequence of the last change, self-referential
types based on the output of a subscription resolver can no longer be
created. This does not mean anything for users, but causes lifetime
issues in the implementation of merged objects. I fixed it with a bit of
a hack, but this'll have to be looked into further.
- `InputValueError` now has a generic parameter - it's kind of weird but
it's necessary for ergonomics. It also improves error messages.
- The `ErrorExtensions` trait has been removed. I didn't think the
`extend` method was necessary since `From` impls exist. But the
ergonomics are still there with a new trait `ExtendError`, which
is implemented for both errors and results.
- `Response` now supports serializing multiple errors. This allows for
nice things like having multiple validation errors not be awkwardly
shoved into a single error.
- When an error occurs in execution, data is sent as `null`. This is
slightly more compliant with the spec but the algorithm described in
<https://spec.graphql.org/June2018/#sec-Errors-and-Non-Nullability> has
yet to be implemented.
2020-09-29 19:06:44 +00:00
async fn parse_with_extensions_result(& self) -> Result< i32 > {
2020-05-12 09:05:25 +00:00
// the trait `error::ErrorExtensions` is not implemented
// for `std::num::ParseIntError`
2020-10-10 02:32:43 +00:00
"234a".parse().extend_err(|_, e| e.set("code", 404))
2020-05-12 09:05:25 +00:00
}
```
however this does:
```rust,ignore,does_not_compile
Rework errors
This completely overhauls the error system used in async-graphql.
- `Error` has been renamed to `ServerError` and `FieldError` has been
renamed to just `Error`. This is because `FieldError` is by far the most
common error that users will have to use so it makes sense to use the
most obvious error name. Also, the current name didn't make sense as it
was used for things other than field errors, such as the data callback
for websockets.
- `ServerError` has been made completely opaque. Before it was an enum
of all the possible errors, but now it just contains an error message,
the locations, the path and extensions. It is a shame that we lose
information, it makes more sense as _conceptually_ GraphQL does not
provide that information. It also frees us to change the internals of
async-graphql a lot more.
- The path of errors is no longer an opaque JSON value but a regular
type, `Vec<PathSegment>`. The type duplication of `PathSegment` and
`QueryPathSegment` is unfortunate, I plan to work on this in the future.
- Now that `ServerError` is opaque, `RuleError` has been removed from
the public API, making it simpler.
- Additionally `QueryError` has been completely removed. Instead the
error messages are constructed ad-hoc; I took care to never repeat an
error message.
- Instead of constructing field-not-found errors inside the
implementations of field resolvers they now return `Option`s, where a
`None` value is representative of the field not being found.
- As an unfortunate consequence of the last change, self-referential
types based on the output of a subscription resolver can no longer be
created. This does not mean anything for users, but causes lifetime
issues in the implementation of merged objects. I fixed it with a bit of
a hack, but this'll have to be looked into further.
- `InputValueError` now has a generic parameter - it's kind of weird but
it's necessary for ergonomics. It also improves error messages.
- The `ErrorExtensions` trait has been removed. I didn't think the
`extend` method was necessary since `From` impls exist. But the
ergonomics are still there with a new trait `ExtendError`, which
is implemented for both errors and results.
- `Response` now supports serializing multiple errors. This allows for
nice things like having multiple validation errors not be awkwardly
shoved into a single error.
- When an error occurs in execution, data is sent as `null`. This is
slightly more compliant with the spec but the algorithm described in
<https://spec.graphql.org/June2018/#sec-Errors-and-Non-Nullability> has
yet to be implemented.
2020-09-29 19:06:44 +00:00
async fn parse_with_extensions_result(& self) -> Result< i32 > {
2020-05-12 09:05:25 +00:00
// does work because ErrorExtensions is implemented for & ParseIntError
"234a"
.parse()
2020-10-10 02:32:43 +00:00
.map_err(|ref e: ParseIntError| e.extend_with(|_, e| e.set("code", 404)))
2020-05-12 09:05:25 +00:00
}
```