Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tratamento de Erros #6

Open
gabsprates opened this issue Oct 11, 2017 · 2 comments
Open

Tratamento de Erros #6

gabsprates opened this issue Oct 11, 2017 · 2 comments
Assignees

Comments

@gabsprates
Copy link
Member

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
Copy link

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
Copy link
Member Author

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants