This repository was archived by the owner on Aug 26, 2025. It is now read-only.
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 is field-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
How it works
At the moment, an error is rendered like this:
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:
What to do:
A possible format could be:
This error format removes the drawbacks, whether to use
key/valueobjects on theargumentsor just a map is another thing to consider.