Manejo adecuado de errores en la capa de servicio de Nest.js

En el desarrollo de una API utilizando Nest.js y MikroORM, es crucial implementar un manejo de errores efectivo en la capa de servicio. Este artículo aborda los problemas y preguntas comunes relacionados con el manejo de errores en esta capa, basándose en un método de actualización de proyectos como ejemplo.

Ejemplo de método de actualización

El siguiente método update ilustra la lógica necesaria para actualizar un proyecto:

async update(
  id: number,
  updateProjectDto: UpdateProjectDto,
): Promise<Projects> {
  try {
    const project = await this.projectRepository.findOneOrFail(id);
    if (updateProjectDto.client_id) {
      project.client = await this.clientService.findOne(
        updateProjectDto.client_id,
      );
    }

    this.projectRepository.assign(project, updateProjectDto);
    await this.projectRepository.getEntityManager().flush();
    return project;
  } catch (error) {
    this.logger.error('Error updating project', error);
    throw error;
  }
}

Además, la metodología de búsqueda de clientes se presenta a continuación:

async findOne(id: number) {
  try {
    return await this.clientsRepository.findOneOrFail({ id });
  } catch (error) {
    this.logger.error(`Error finding client`, error);
    throw error;
  }
}

Preguntas y soluciones

1. ¿Cuándo deberíamos envolver nuestra lógica de negocio dentro de un try-catch?

Es recomendable envolver la lógica de negocio en un bloque try-catch siempre que exista la posibilidad de que ocurra un error que requiere manejo específico. Esto incluye llamadas a repositorios, validaciones y cualquier operación crítica. Un manejo adecuado permite registrar el error y realizar acciones específicas, como la limpieza de recursos.

2. ¿Deberíamos usar try-catch para cada método en nuestra API o dejar que los errores se propaguen?

Efectivamente, es recomendable utilizar try-catch en métodos donde se desea mejorar el control de flujo o se requieren acciones específicas ante un error. Sin embargo, si un método es muy simple y no realiza un manejo especial de errores, se puede permitir que los errores se propaguen. Esto simplifica el código y aún permite que un nivel superior maneje los errores adecuadamente.

3. ¿Debería el servicio lanzar HTTPExceptions?

En términos de arquitectura limpia, la capa de servicio no debería lanzar HTTPExceptions, ya que su responsabilidad es la lógica de negocio, no el manejo de la presentación. Sin embargo, es comprensible que, por simplicidad, en ciertos casos se elija lanzar excepciones HTTP desde esta capa. La clave es mantener la consistencia y documentar claramente este comportamiento.

Conclusión

El manejo de errores en la capa de servicio de Nest.js debe ser meticuloso para asegurar que la aplicación sea robusta y fácil de mantener. Envolver la lógica de negocio en bloques try-catch, decidir cuándo permitir la propagación de errores y definir las excepciones a lanzar son decisiones críticas que impactan en el diseño y la eficiencia de la API.