[Dúvida] Tratamento de erros | Node.js: lidando com buscas, filtros, paginação e erros em uma API

Uma vez que eu capturo o meu erro, e retorno ele...

catch (error) {
      res.status(Consts.ERR).send({ error: `${Consts.ERR_GET_WEAPON_BY_ID} ${req.params.id} - ${error.message}` });
  }

Não deveria ser responsabilidade do front-end trata-lo? Eu não entendo a necessidade de colocar condicional de erros dentro do endpoint, sendo que é possível retornar exatamente o erro que surgiu.

Veja:

{
    "error": "Ocorreu um erro ao buscar pela arma de ID =  6485e5aaad1084605f44a4f5H - Cast to ObjectId failed for value \"6485e5aaad1084605f44a4f5H\" (type string) at path \"_id\" for model \"Weapons\""
}

Apesar de não ser uma mensagem bonita, ela é retornada do lado da API, deveria ser responsabilidade do front trata-la, não?

Oi, Brenda, tudo bem?

Interessante sua dúvida! O principal ponto dessa questão é que na verdade devemos evitar de enviar para o cliente detalhes técnicos internos da nossa API, principalmente informações do banco de dados que possam ser sensíveis.

Mesmo que o front-end possa tratar a nossa requisição e mostrar uma mensagem de erro mais apropriada ao usuário final, ainda assim estamos expondo informações da API nas respsotas. Nada garante que o front-end vai de fato tratar todas as mensagens. E, mesmo que trate, ainda assim seria possível uma pessoa mal intencionada fazer requisições diretamente para a nossa API e tentar obter e explorar informações sensíveis a partir das mensagens de erros.

O erro que você enviou, por exemplo, contém o nome do modelo e o erro interno que aconteceu no MongoDB. Essas informações podem ser úteis para um atacante entender a estrutura do banco de dados ou explorar vulnerabilidades.

Essas mensagens de erros do Banco de Dados servem apenas para as pessoas desenvolvedoras da API, justamente para sabermos o que aconteceu e para que possamos tratar melhor esses erros em tempo de desenvolvimento.

Assim, superada a motivação de proteger detalhes internos do sistema, ainda assim existem casos onde é interessante fornecer mensagens de erro mais adequadas para o cliente. Por exemplo, se tiver havido um erro de requisição por parte do cliente, nós não devemos retornar um erro genérico de servidor com código de status 500. Se o usuário passar um ID inválido, então o erro deve informar apropriadamente que foi fornecida uma informação inválida e o código de status deve ser 400.

Ou seja, ao mesmo tempo que não devemos expor detalhes internos da API, devemos retornar informações semânticas que sejam úteis ao usuário final.

Por fim, sobre colocar condicionais no método de controlador, nós iremos refatorar esse código nos próximos vídeos para que haja um tratamento de erros mais robusto e uma melhor separação de responsabilidades de cada arquivo.

Espero ter ajudado! Aproveitei e fiz uma atividade logo depois desse vídeo. Abraços e bons estudos :)