Hi strawberry-django team,

First, I just want to say how much I appreciate the work you’re doing! I’ve been following the development of Strawberry closely, and I am already using it in a number of projects. Having just updated a couple of projects to the latest version I noticed that Strawberry is now using a generic approach to handle mutation errors, such as:

type OperationMessage {
  kind: OperationMessageKind!
  message: String!
  field: String
  code: String
}

This seems like a flexible way to handle a wide variety of errors with a minimal schema. However, since you've not yet released a 1.0 version, I wanted to start a conversation around this choice and share a different approach that I’ve found useful in production, particularly for its explicitness and flexibility. (I started using this solution before there were docs written for strawberry-django).

I use an InputError interface, which allows for specific error types like ValidationError, NotAuthenticatedError, etc.:

interface InputError {
  message: String!
}

type ValidationError implements InputError {
  message: String!
  fields: [FieldError!]!
}

type FieldError {
  field: String!
  messages: [String!]!
}

type NotAuthenticatedError implements InputError {
  message: String!
}

type NotAuthorisedError implements InputError {
  message: String!
}

type DoesNotExistError implements InputError {
  message: String!
}

# And you can create your own specific types.
type OurCustomError implements InputError {
  message: String!
  libraryId: Int!
}

I like this approach because:

• It ensures all errors have a common message field, which can be easily queried (... on InputError { message }).
• It allows for more granular error types, where I can query additional specific fields (e.g., ... on ValidationError { fields { field, messages } }).
• Using __typename on the frontend allows me to handle each error type with specific UI responses.
• Errors are strongly typed and explicit.

I’d love to hear your thoughts on the merits of both approaches. I’m curious about the design decisions that led to the current generic error handling and whether there’s room for considering more specific error types down the road. Or are there issues with my approach that make it unfeasible?

Looking forward to your thoughts and discussion!

Thanks again for all the hard work.