search

sapucaiatech / eventos-api

:memo: :date: API de eventos do Sapucaia Tech e parceiros
MIT License
1 stars 1 forks source link

Tratamento de Erros #6

Open gabsprates opened 7 years ago

gabsprates commented 7 years ago

Através da discussão do PR #5 percebemos que não foi implementado nenhum tratamento de erros em na maioria do programa, com exceção da parte de login.

No primeiro momento, acredito que é necessário tratar as rotas de uma maneira geral, daí todo erro lançado cairia no catch geral.

O que acham melhor?

filhocodes commented 7 years ago

Não acho que seja algo difícil de discutir

  1. Defina um módulo exception-handler.js que exporte um middleware que será responsável por receber os erros (no caso, seguindo o padrão connect, seria o último middleware da nossa aplicação).
  2. Dentro desse módulo vamos ter diversas funções, que serão chamadas de acordo com o erro que o middleware receber. Ex.: Se o middleware receber uma string ou um objeto Error sem nenhuma propriedade a mais, chama uma função geral, se o middleware receber um err instanceof AuthError, chama uma função de erro de autenticação.
  3. Todas as funções devem exportar a mesma assinatura para determinar uma mensagem de erro. Eu gosto muito do formato do JSON-API, onde sua resposta tem sempre um wrapper, se a resposta foi favorável a requisição ele sempre tem um campo data com o conteúdo da resposta e opcionalmente um meta para informar links de paginação, ou a quantidade de requisições restantes dentro do limite; e se a resposta não foi favorável ele retorna um campo error, com o conteúdo da mensagem de erro. Vale lembrar que essa assinatura da resposta está associado a quem vocês vão permitir que utilizem a API. Ou seja, se for apenas nossas aplicações, não seria uma prática ruim deixar a resposta livre, sem uma estrutura (desde que corretamente documentada), mas se você não se importa que outras pessoas utilizem nossa API nas aplicações deles, devemos sim padronizar as respostas, para impedir que atualizações na nossa API quebrem as aplicações clientes (independente se API possui sistemas como versionamento ou etc)

A principal vantagem do exception-handler.js (ou exceptions/handler.js, ou whatever), é a definição de uma área da sua aplicação que trabalhe com erros. Se você precisar adicionar um erro ao mais, como por exemplo mensagens de erro que indiquem que algum serviço que utilizamos está fora do ar, basta ir nesse arquivo, criar uma função, e expandir o middleware. É mais prático do que lotar um middleware dentro do server.js com essas condições.

gabsprates commented 7 years ago

@marcossffilho cara, lembrei de uma coisa aqui. Já temos o middleware de tratamento de erros. Só precisamos passar eles pelo next(), vou fazer o teste e digo se deu certo.