When using GraphQL/Apollo Server, should an error be thrown for no database results?

Question

If a resolver gets a user from a database for example and no user was not found, should an error be thrown? What is best practice for no data found?

Answer 1

There's a case to be made for simply returning null, rather than throwing an error, particularly in this scenario. The errors part of your response will includes two general types of errors:

• Execution errors that result from some thrown error or rejected Promise encountered during execution
• Response validation errors that result from the response not conforming to the schema

In both of these cases, something bad and unexpected happened server-side. As a client, I need to maybe file a defect, open an issue or go yell at somebody 3 cubicles over. But the point is, these errors shouldn't occur in the normal course of things.

On the other hand, let's consider looking up a user by their username or some other identifier. Rather than a search that returns an array of users, let's assume we're using an exact match and only returning a single user.

type Query {
  user(username: String!): User
}

In a scenario like this, not finding a matching user in the database some of the time is probably expected. As long as the field is nullable, the client will know to expect either a User or null, and can handle either scenario just fine.

If we throw an error, the field will still return null, but now we'll also see an error in our errors array. The client will now have to do additional work to determine if the error occurred because there was no user found, or if something else went wrong (after all, if a server error occurred, we may need to take additional action, for example alerting the user to the fact). Moreover, our errors array is no longer an indicator of response "health", since it may include errors that are being thrown as part of our regular business logic.