Tengo una pequeña aplicación de prueba (un laboratorio de pruebas) con un AppControler
y un AppService
, AppController
tiene un punto final GET
y envía solicitudes de carga a AppService
, que tiene dos métodos asincrónicos.
Servicio de aplicaciones
async requestTesting (payload): Promise<void> { // This is what's being called from the controller if(payload) { await this.validateErrorHandling(payload) } console.log('TESTING', payload) // DO STUFF } async validateErrorHandling(payload): Promise<void> { console.log('DO STUFF') if(payload && payload.number > 2) { // This is true throw new Error() } }
Cuando requestTesting llama a validateErrorHandling, el segundo método verificará esa condición (si es verdadera) y arrojará un error. Estoy acostumbrado a hacer esto con un filtro de excepción en casos de uso reales, pero en este caso muy específico, cada vez que llamo al punto final de mi controlador y aparece ese error en mi AppService
, se muestra lo siguiente:
UnhandledPromiseRejection: This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). The promise rejected with the reason "........".
Y no puedo hacer ninguna otra solicitud a través del cartero hasta que reinicie la aplicación. El cartero muestra:
Error: connect ECONNREFUSED 127.0.0.1:3000
Ahora, soy consciente de que un intento/captura debería solucionar esto, pero estoy tratando de entender por qué esto detiene toda mi aplicación en lugar de detener solo la ejecución de la función, como nunca me había sucedido antes, y si intento tirarlo en cualquier otro lugar, simplemente funciona.
Ahora, ambos métodos tienen un tipo de retorno Promise<void>
, pero si validateErrorHandling arroja un error, todo debería detenerse y ese console.log('TESTING', payload)
no debería ejecutarse (como si fuera una lógica de negocios). Me temo que no se trata solo de mi tontería, sino que en realidad podría estar perdiéndome algo.
La razón por la que arrojamos un error es que queremos decirle a la aplicación frontal que algo salió mal. Para lograr esto, es mejor lanzar un error HTTP en lugar de simplemente lanzarlo. Así que aquí está el código:
throw new UnprocessableEntityException({ errorCode: UpdateProductErrorStatusEnum.DeviceNotReported, message: UpdateProductErrorMsgEnum.DeviceNotReported, });
Tienes dos opciones. Primero lanza el error en el propio servicio, segundo para lanzar un Error (como lo hiciste) y atraparlo en la capa del controlador. Cada forma tiene sus pros y sus contras. Lanzar el controlador es mejor porque el controlador está diseñado para manejar cosas relacionadas con HTTP, y el servicio se crea solo para cosas lógicas. Pero lanzar el controlador hace que el controlador se ensucie y tal vez su código no esté limpio.
Consulte aquí para obtener más información: https://docs.nestjs.com/exception-filters