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 (Obligatorio) - 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 (Obligatorio) - 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

1{ 2    "message": "Invalid requests", 3    "code": "INVALID_PARAMETERS", 4    "description": "Invalid requests", 5    "args": [ 6        { 7            "arg": "REASON", 8            "value": "customerNumber is required" 9        } 10    ], 11    "status": "400 BAD_REQUEST" 12}

Estructura de excepción para api gRPC

1domain: Mirror Strategy 2 metadata 3 args: [] 4 code: FIELD_LENGTH_VALIDATION_FAILED 5 description: One or more fields length validation failed. 6 message: VPLVO2472S : XML ELEMENT DATA EXCEEDSCARD_NBR 7 status: 400 BAD_REQUEST 8@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