Para este proyecto se ocupo la libreria ffss-core-chassis para hacer uso de:
Modelos de error (DTOs)
Excepciones personalizadas
Controller advice y handlers
Por lo cual los componentes que se mencionaran en esta documentación se encontrarán en dicha librería, principalmente en los módulos common y starter.
Modelo de error
Cuando se propaguen excepciones por REST o gRPC estas se devolverán bajo el siguiente modelo:
Respuesta de ejemplo:
A continuación se describe cada campo:
message Mensaje personalizado de la excepción.
code (Obligatorio). Nombre del Enum que represente el error. Este enum se debe de agregar en la clase com.femsa.digital.ffss.common.domain.FFSSErrorCode que se encuentra en ffss-core-chassis, módulo fss-common
description Valor del Enum que represente el error. Este enum es el mismo descrito en el campo anterior de code.
args Arreglo de errores. Cada error tiene la propiedad arg y value (llave y valor) respectivamente.
status HttpStatus el cual debe estar formado con el valor (primeros 3 caracteres) y el nombre
¿Como propagar una excepción?
Existen dos formas de llevar a cabo la propagación de excepciones.
1.- Por medio de throw new <Exception>
Para esta forma se tienen que usar las excepciones ya creadas que se encuentran dentro del módulo ffss-common
y propagarlas de la siguiente manera:
2.- Llamando al método handleNotSuccessfulResponse de la clase ErrorResponseProcessor.
Por ejemplo:
Para esta forma se tiene que llenar un objeto de tipo ErrorResponseDTO:
¿Que handlers cachan las excepciones para Apis REST y gRPC?
Para peticiones de tipo REST la clase BaseControllerAdvice.java procesará los excepciones de tipo AbstractException, Exception, StatusRuntimeException, MethodArgumentNotValidException, etc.
Para peticiones de tipo gRPC la clase GlobalExceptionHandlerInterceptor.java será la encargada de cacharlas en primera instancia y posterior se procesaran en la clase ExceptionHandlerStrategy.java. Aqui se procesaran las peticiones de tipo AbstractException, Exception y StatusRuntimeException principalmente
Estructura de excepcion para api REST
{
"message": "Invalid requests",
"code": "INVALID_PARAMETERS",
"description": "Invalid requests",
"args": [
{
"arg": "REASON",
"value": "customerNumber is required"
}
],
"status": "400 BAD_REQUEST"
}
Estructura de excepción para api gRPC
domain: Mirror Strategy
metadata
args: []
code: FIELD_LENGTH_VALIDATION_FAILED
description: One or more fields length validation failed.
message: VPLVO2472S : XML ELEMENT DATA EXCEEDSCARD_NBR
status: 400 BAD_REQUEST
@type: type.googleapis.com/google.rpc.ErrorInfo
Para poder visualizar las excepciones por gRPC se recomienda usar Postman ya que en la pestaña Response se nos mostrará de la siguiente manera:
Ejemplos de excepciones Api REST
400 - BAD REQUEST
Los errores en los campos de entrada se concatenan en una sola cadena separados por pipes.
500 - INTERNAL SERVER ERROR
401 - UNAUTHORIZED
Ejemplos de excepciones por gRPC
3 - INVALID ARGUMENT
Para los errores gRPC , el campo args tendrá como valor una cadena json para almacenar el arreglo de errores.
13 INTERNAL
Add Comment