In order to standardise all the errors issued by services, for example, it is useful to manage internal errors using exceptions.
The first advantage is the response feedback on the api, for example:
http://localhost:3333/v1/patients
{
"message": "Unauthorized",
"status": 401,
"code": "E_AUTHENTICATION_UNAUTHORIZED"
}This is the return when the user is not logged in, but the structure in the event of a different error is ‘identical’:
{
"message": "Cannot access",
"status": 403,
"code": "E_PATIENT_FETCH_UNAUTHORIZED"
}This convention means that when we write our tests, we can expect the right code, which means that when we add features or even fix them, we can guarantee that the api has not been regressed!
In order to standardise all the errors issued by services, for example, it is useful to manage internal errors using exceptions.
The first advantage is the response feedback on the api, for example:
http://localhost:3333/v1/patients{ "message": "Unauthorized", "status": 401, "code": "E_AUTHENTICATION_UNAUTHORIZED" }This is the return when the user is not logged in, but the structure in the event of a different error is ‘identical’:
{ "message": "Cannot access", "status": 403, "code": "E_PATIENT_FETCH_UNAUTHORIZED" }This convention means that when we write our tests, we can expect the right code, which means that when we add features or even fix them, we can guarantee that the api has not been regressed!