‫Jonas: Neste vídeo, vamos implementar
‫alguma lógica para enviar diferentes mensagens de erro
‫para o ambiente de desenvolvimento e produção.
‫Então, agora, estamos enviando esta mesma mensagem de resposta aqui
‫basicamente para todos, não importa se estejamos em
‫desenvolvimento ou em produção.
‫Mas a ideia é que, na produção, queremos vazar
‫o mínimo possível de informações sobre
‫nossos erros para o cliente.
‫Nesse caso, queremos apenas enviar uma
‫mensagem agradável e amigável para
‫que o usuário saiba o que está errado.
‫Por outro lado, quando
‫o desenvolvimento é escrito, queremos obter o máximo possível
‫de informações sobre o erro ocorrido e queremos
‫isso na mensagem de erro que está voltando.
‫Então poderíamos registrar essas informações também no
‫console, mas acho que é muito mais útil
‫ter essas informações direto no carteiro, neste caso.
‫Então, já sabemos distinguir entre o ambiente de
‫desenvolvimento e o ambiente de produção.
‫E então, vamos fazer isso.
‫Portanto,
‫se o processo. env. node_env é
‫igual a development, então queremos
‫enviar um tipo de
‫erro e, se
‫estivermos em produção, queremos enviar um erro mais simples.
‫Tudo bem.
‫Tão igual à produção.
‫Tudo bem, então vamos pegar este aqui, então,
‫novamente, quando o desenvolvimento
‫for escrito, queremos obter todas as informações que pudermos.
‫Isso também imprime ou responde com a pilha de erros aqui.
‫Então erre. empilhar, e então
‫imprimiremos também o erro inteiro.
‫Digamos erro e configure-o corretamente.
‫Então, por
‫outro lado, vamos agora copiar novamente.
‫Quando estamos em produção, não queremos a pilha
‫e também não queremos o erro completo.
‫Então, realmente, apenas o status e a mensagem.
‫Isso aqui parece
‫meio confuso, então vamos exportar para
‫suas próprias funções e também porque vamos
‫adicionar muito mais código aqui, neste outro branch.
‫É um pouco mais claro tê-los em suas
‫próprias funções separadas.
‫Então, digamos
‫que const send error para
‫dev e essa função receba o
‫erro, e também precisamos passar o assunto da resposta.
‫Isso porque é assim que podemos
‫enviar a resposta, certo?
‫Portanto, precisamos do assunto da resposta para poder executar
‫este código.
‫Aqui, vamos apenas chamar send
‫error dev com
‫o
‫erro e a resposta.
‫Então, aqui
‫embaixo, teremos
‫de enviar produção de
‫erro,
‫os mesmos argumentos.
‫E então aqui, o mesmo.
‫Então isso foi fácil, vamos agora passar para o próximo
‫nível e falar sobre erros operacionais novamente.
‫Para isso, deixe-me abrir a classe de erro
‫do aplicativo que criamos e vamos lembrar
‫que marcamos todos
‫os erros que criamos, usando AppError operacional definido como verdadeiro.
‫Portanto, todos os erros
‫que criamos serão basicamente erros operacionais.
‫Na verdade, são apenas esses erros operacionais para
‫os quais queremos enviar a mensagem de
‫erro ao cliente.
‫Pelo menos em produção.
‫Portanto, quando, por outro lado, temos um erro de programação, ou
‫algum outro erro desconhecido que venha,
‫por exemplo, de um pacote de terceiros,
‫não queremos enviar nenhuma mensagem de erro sobre isso para
‫o cliente em produção.
‫E isso não adianta.
‫Esta é uma propriedade operacional aqui em nosso controlador de erro.
‫Lembra que eu já falei
‫sobre fazer isso quando criamos essa aula, certo?
‫Vamos agora enviar a produção de erros e fazer
‫esse teste.
‫Se houver erro. isOperational apenas
‫nesse caso, queremos realmente enviar esse erro aqui.
‫Em todos
‫os outros casos, simplesmente
‫enviaremos uma mensagem de erro muito genérica ao cliente.
‫Então, digamos, res. status e vamos simplesmente
‫enviar um código 500 genérico e, em
‫seguida, json.
‫O status será erro.
‫Então, vamos enviar uma mensagem genérica, dizendo que
‫algo
‫deu muito errado.
‫Portanto, fazer algo assim é um procedimento padrão.
‫Deixe-me comentar um pouco do código aqui.
‫Portanto, este é um erro operacional em que confiamos.
‫Aqui queremos enviar uma mensagem ao cliente.
‫Mas, neste caso
‫aqui, temos um erro desconhecido
‫e, portanto, não queremos vazar os detalhes para o cliente.
‫Então, vamos enviar esta mensagem para o cliente e
‫também para nós mesmos.
‫Para nós, desenvolvedores, queremos saber
‫se esse tipo de erro estranho, inesperado e
‫desconhecido ocorreu e vamos realmente registrá-lo no console.
‫Primeiro, registraremos o
‫erro e, em seguida, enviaremos uma mensagem genérica.
‫Digamos apenas console. erro, então isso é um pouco
‫como o console. log, mas
‫é realmente específico para erros e
‫acredito que a saída ficará um pouco diferente.
‫Portanto, erro, vamos adicionar alguns emojis aqui para torná-los visíveis em
‫nossos logs
‫e, em seguida, registrar o erro também.
‫Agora, existem bibliotecas de registro reais no mpm, que poderíamos
‫usar aqui em vez
‫de apenas ter este console simples. erro, mas apenas
‫registrar o erro no console o tornará
‫visível nos registros da plataforma
‫de hospedagem que você está usando.
‫Acho que por enquanto, neste tipo de aplicação simples, isso é
‫o suficiente.
‫Por exemplo, vamos usar o
‫Heroku no final do curso para implantar nosso aplicativo.
‫Então, quando um erro como
‫esse ocorrer, ele será registrado no console.
‫Na plataforma Heroku, então, temos acesso a esses logs.
‫Podemos continuar olhando esses registros e, aí,
‫encontraremos esses erros inesperados para
‫que possamos corrigi-los.
‫No momento, já estamos construindo aqui um
‫mecanismo sofisticado de tratamento de erros
‫do mundo real.
‫Então, vamos recapitular rapidamente o que acabamos de fazer aqui.
‫Estamos distinguindo entre erros no desenvolvimento e
‫na produção.
‫Quando estamos em produção, enviamos o erro
‫usando esta função aqui,
‫que então enviará o máximo de detalhes possível ao
‫cliente, para
‫que realmente obtenhamos todas as
‫informações a fim de nos livrarmos do bug.
‫Se for um
‫erro de programação ou operacional,
‫ainda queremos ver tudo o que está acontecendo.
‫Quando estamos
‫em produção, que é indiscutivelmente
‫a parte mais importante de nosso aplicativo,
‫distinguimos entre erros
‫operacionais, portanto, erros que conhecemos e
‫confiamos, e outros erros, que podem ser inesperados.
‫Se o erro for operacional, por exemplo, o usuário
‫tentou acessar uma rota que não existe, ou
‫tentou inserir dados inválidos, todos esses
‫são erros operacionais.
‫Então, podemos enviar mensagens de erro apropriadas, para que
‫o cliente saiba o que deu errado.
‫Por outro lado, temos esses erros
‫desconhecidos ou inesperados e, nesse
‫caso, dizemos muito simplesmente, algo deu errado.
‫Em seguida, registre o erro também em nosso
‫console, para que possamos saber o que aconteceu e podermos corrigi-lo.
‫Agora, para que isso funcione,
‫há algo muito, muito importante que
‫precisamos fazer.
‫Neste momento existem erros que
‫são, por exemplo, provenientes do MongoDB, que não marcamos como operacionais.
‫Nesse caso, eles seriam agora simplesmente tratados usando esta
‫mensagem de erro genérica aqui.
‫Por exemplo, um erro de validação.
‫No momento, esse é um erro que vem
‫do MongoDB e não de nossa própria classe de erro de aplicativo.
‫Não criamos esses erros por nós mesmos.
‫Novamente, eles agora não estão marcados como operacionais, mas é
‫claro que precisamos marcá-los como operacionais para que possamos
‫enviar a mensagem de erro apropriada
‫de volta ao cliente.
‫No exemplo que acabei de mencionar, os
‫dados de entrada são inválidos.
‫Existem dois ou três outros erros que precisamos
‫marcar como operacionais.
‫Então
‫faremos isso aqui.
‫Então, neste bloco
‫else, faremos isso nas próximas duas aulas.