GraphQL：返回空值与抛出错误答案

【问题标题】：GraphQL: Returning null vs Throwing ErrorGraphQL：返回空值与抛出错误
【发布时间】：2018-08-31 04:22:03
【问题描述】：

如果出现错误，我总是想知道是应该返回null还是抛出错误。

假设我有一个类型Person：

type Person {
    firstName: String!
    lastName: String!
}

我想让客户端搜索特定用户。这可以通过两种方式完成：

使用可空类型并在未找到用户时可能返回null：

type Query {
    getPerson(firstName: String!): Person
}

使用不可为空的类型并在找不到用户时抛出错误：

type Query {
    getPerson(firstName: String!): Person!
}

有正确的方法吗？

【问题讨论】：

标签： graphql

【解决方案1】：

有趣的问题！

首先我要说明的是，响应的“错误”部分实际上只针对开发人员错误（这意味着由开发人员导致的错误，无论是在后端还是在前端）。对于 API 被滥用时发生的错误，例如提供了错误的参数（HTTP 400-403），或者内部出现问题（HTTP 500）。在这种情况下，有些东西被破坏了，用户不需要采取任何行动，但开发人员需要采取行动。未找到（HTTP 404）非常特殊，因为它通常是由您的 APP 的用户引起的（例如，您尝试访问不存在的个人资料页面）。在这种情况下，我们希望直接向用户提供反馈。 “此配置文件不存在返回主页” 大多数客户端工具不能很好地处理 GraphQL 错误。这就是为什么应该向用户显示的错误应该是您的响应模式的一部分。 This awesome blog post 详细介绍了该主题。

现在我认为您不需要在 API 中返回专用的 GetPersonPayload 类型，但这当然是可能的：

type GetPersonPayload {
  person: Person
  errors: [PayloadError!]!
}

type Query {
   getPerson(firstName: String!): GetPersonPayload
}

总结一下：我肯定会返回一个可以为空的人，并且 - 根据您的架构应该如何面向未来/企业 - 您甚至可能希望返回链接文章中描述的特殊有效负载类型。

【讨论】：

你会说我应该只为意外错误抛出错误吗？因为寻找一个不存在的人是很可能发生的事情。
不，我的意思是永远不应该抛出最终用户错误，而是在模式中以专用错误对象类型返回。因此，用户输入不应导致响应的“错误”部分出错，因为 graphql 客户端在处理它们时非常糟糕，并且损坏字段中返回的 null 值很可能会破坏您的模式协定。