This repository was archived by the owner on Aug 26, 2025. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 7
Improve the error format #3
Copy link
Copy link
Open
Labels
enhancementNew feature or requestNew feature or request
Description
How it works
At the moment, an error is rendered like this:
{
"type": "field-validation-error",
"message": "An error message",
"field": "email"
}
The fields have the following meaning:
type-> the type of error, or error category (mandatory).message-> a user friendly message rendered on the user language (mandatory).field-> this exists only because the type isfield-validation-error.
How to improve it
There are some drawbacks on this approach:
- As there are several possible error types, this leads to several possible extra fields, hence, being hard to create types.
- Reacting against specific errors is painful, we need to match against the error message in order to detect specific errors.
- Extracting more information about the error could only be done by parsing the error message.
What to do:
- Render unique error identifiers.
- Render possible arguments related to the error.
A possible format could be:
{
"id": "email-format-error",
"type": "field-validation-error",
"message": "The given email format is incorrect",
"details": [
{ "key": "email", "value": "someone@something.com" },
{ "key": "field", "value": "email" }
]
}
This error format removes the drawbacks, whether to use key/value objects on the arguments or just a map is another thing to consider.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
enhancementNew feature or requestNew feature or request