GraphQL errors are different from traditional REST error handling because a response can contain both data and errors.

For example:

{
  "data": {
    "user": null
  },
  "errors": [
    {
      "message": "User not found"
    }
  ]
}

The exact result depends on the field's nullability and the execution failure.

GraphQL errors can originate from validation, parsing, variable coercion, resolver execution, authorization, or other layers.

Consider:

type Query {
  user(id: ID!): User
}

Because user is nullable, an execution failure can result in user: null alongside an error.

Now consider:

type Query {
  user(id: ID!): User!
}

The non-null contract changes error propagation. If the resolver cannot produce a valid non-null user, GraphQL can propagate null to a nullable parent field, potentially causing a larger portion of the response to become null.

Production APIs should also avoid leaking sensitive internal information through error messages. Database stack traces, credentials, internal hostnames, and implementation details should not become client-facing errors.

A consistent error classification strategy helps clients distinguish expected business failures from unexpected infrastructure failures.