Необходимо сделать простой возврат null, а не выдавать ошибку, особенно в этом сценарии.Часть errors вашего ответа будет включать в себя два основных типа ошибок:
- Ошибки выполнения, возникшие в результате какой-либо сгенерированной ошибки или отклоненного обещания, возникшего во время выполнения
- Ошибки проверки ответа, возникшие в результатеиз ответа, не соответствующего схеме
В обоих этих случаях что-то плохо и неожиданно произошло на стороне сервера.Как клиент, мне, возможно, нужно зарегистрировать дефект, открыть проблему или кричать на кого-то на 3 ячейки.Но дело в том, что эти ошибки не должны происходить в обычном порядке.
С другой стороны, давайте рассмотрим поиск пользователя по его имени пользователя или другому идентификатору.Вместо того, чтобы искать, который возвращает массив пользователей, давайте предположим, что мы используем точное совпадение и возвращаем только одного пользователя.
type Query {
user(username: String!): User
}
В подобном сценарии не найдено соответствующего пользователя в базе данных.Некоторое время, вероятно, ожидается.Пока поле имеет значение NULL, клиент будет знать, что он ожидает пользователя или NULL, и может отлично справиться с любым сценарием.
Если мы сгенерируем ошибку, поле все равно вернет NULL, но теперь мыВы также увидите ошибку в нашем массиве errors.Теперь клиенту придется выполнить дополнительную работу, чтобы определить, произошла ли ошибка из-за того, что не было найдено ни одного пользователя, или если что-то пошло не так (в конце концов, если произошла ошибка сервера, нам может потребоваться принять дополнительные меры, например, предупредитьпользователь к тому факту).Более того, наш массив errors больше не является индикатором ответа "здоровье", поскольку он может включать в себя ошибки, которые генерируются как часть нашей обычной бизнес-логики.