1 00:00:01,150 --> 00:00:03,353 ‫Jonas: Neste vídeo, vamos implementar 2 00:00:03,353 --> 00:00:06,390 ‫alguma lógica para enviar diferentes mensagens de erro 3 00:00:06,390 --> 00:00:09,173 ‫para o ambiente de desenvolvimento e produção. 4 00:00:10,810 --> 00:00:14,490 ‫Então, agora, estamos enviando esta mesma mensagem de resposta aqui 5 00:00:14,490 --> 00:00:17,389 ‫basicamente para todos, não importa se estejamos em 6 00:00:17,389 --> 00:00:18,920 ‫desenvolvimento ou em produção. 7 00:00:18,920 --> 00:00:21,690 ‫Mas a ideia é que, na produção, queremos vazar 8 00:00:21,690 --> 00:00:23,810 ‫o mínimo possível de informações sobre 9 00:00:23,810 --> 00:00:25,583 ‫nossos erros para o cliente. 10 00:00:26,420 --> 00:00:28,490 ‫Nesse caso, queremos apenas enviar uma 11 00:00:28,490 --> 00:00:30,340 ‫mensagem agradável e amigável para 12 00:00:30,340 --> 00:00:33,070 ‫que o usuário saiba o que está errado. 13 00:00:33,070 --> 00:00:34,858 ‫Por outro lado, quando 14 00:00:34,858 --> 00:00:37,700 ‫o desenvolvimento é escrito, queremos obter o máximo possível 15 00:00:37,700 --> 00:00:40,390 ‫de informações sobre o erro ocorrido e queremos 16 00:00:40,390 --> 00:00:42,950 ‫isso na mensagem de erro que está voltando. 17 00:00:42,950 --> 00:00:45,520 ‫Então poderíamos registrar essas informações também no 18 00:00:45,520 --> 00:00:48,340 ‫console, mas acho que é muito mais útil 19 00:00:48,340 --> 00:00:51,150 ‫ter essas informações direto no carteiro, neste caso. 20 00:00:51,150 --> 00:00:53,660 ‫Então, já sabemos distinguir entre o ambiente de 21 00:00:53,660 --> 00:00:56,010 ‫desenvolvimento e o ambiente de produção. 22 00:00:56,870 --> 00:00:58,213 ‫E então, vamos fazer isso. 23 00:00:59,130 --> 00:00:59,963 ‫Portanto, 24 00:01:01,630 --> 00:01:05,010 ‫se o processo. env. node_env é 25 00:01:06,510 --> 00:01:08,970 ‫igual a development, então queremos 26 00:01:11,810 --> 00:01:13,780 ‫enviar um tipo de 27 00:01:15,530 --> 00:01:17,060 ‫erro e, se 28 00:01:17,060 --> 00:01:21,020 ‫estivermos em produção, queremos enviar um erro mais simples. 29 00:01:21,020 --> 00:01:21,853 ‫Tudo bem. 30 00:01:24,290 --> 00:01:26,913 ‫Tão igual à produção. 31 00:01:30,160 --> 00:01:33,343 ‫Tudo bem, então vamos pegar este aqui, então, 32 00:01:34,390 --> 00:01:36,380 ‫novamente, quando o desenvolvimento 33 00:01:36,380 --> 00:01:39,850 ‫for escrito, queremos obter todas as informações que pudermos. 34 00:01:39,850 --> 00:01:43,763 ‫Isso também imprime ou responde com a pilha de erros aqui. 35 00:01:48,620 --> 00:01:52,300 ‫Então erre. empilhar, e então 36 00:01:52,300 --> 00:01:54,483 ‫imprimiremos também o erro inteiro. 37 00:01:56,240 --> 00:02:00,830 ‫Digamos erro e configure-o corretamente. 38 00:02:00,830 --> 00:02:02,003 ‫Então, por 39 00:02:03,030 --> 00:02:05,183 ‫outro lado, vamos agora copiar novamente. 40 00:02:06,040 --> 00:02:09,350 ‫Quando estamos em produção, não queremos a pilha 41 00:02:09,350 --> 00:02:12,493 ‫e também não queremos o erro completo. 42 00:02:13,490 --> 00:02:16,113 ‫Então, realmente, apenas o status e a mensagem. 43 00:02:19,190 --> 00:02:20,933 ‫Isso aqui parece 44 00:02:21,930 --> 00:02:24,550 ‫meio confuso, então vamos exportar para 45 00:02:24,550 --> 00:02:27,440 ‫suas próprias funções e também porque vamos 46 00:02:27,440 --> 00:02:30,719 ‫adicionar muito mais código aqui, neste outro branch. 47 00:02:30,719 --> 00:02:33,730 ‫É um pouco mais claro tê-los em suas 48 00:02:33,730 --> 00:02:35,180 ‫próprias funções separadas. 49 00:02:36,500 --> 00:02:37,550 ‫Então, digamos 50 00:02:39,540 --> 00:02:41,480 ‫que const send error para 51 00:02:43,930 --> 00:02:46,470 ‫dev e essa função receba o 52 00:02:46,470 --> 00:02:49,903 ‫erro, e também precisamos passar o assunto da resposta. 53 00:02:51,990 --> 00:02:54,930 ‫Isso porque é assim que podemos 54 00:02:54,930 --> 00:02:57,223 ‫enviar a resposta, certo? 55 00:02:58,360 --> 00:03:02,090 ‫Portanto, precisamos do assunto da resposta para poder executar 56 00:03:02,090 --> 00:03:02,933 ‫este código. 57 00:03:04,080 --> 00:03:06,510 ‫Aqui, vamos apenas chamar send 58 00:03:07,410 --> 00:03:08,990 ‫error dev com 59 00:03:09,890 --> 00:03:11,263 ‫o 60 00:03:11,263 --> 00:03:13,073 ‫erro e a resposta. 61 00:03:14,270 --> 00:03:15,483 ‫Então, aqui 62 00:03:17,030 --> 00:03:18,030 ‫embaixo, teremos 63 00:03:18,030 --> 00:03:19,850 ‫de enviar produção de 64 00:03:20,900 --> 00:03:21,783 ‫erro, 65 00:03:24,830 --> 00:03:26,253 ‫os mesmos argumentos. 66 00:03:36,300 --> 00:03:37,500 ‫E então aqui, o mesmo. 67 00:03:43,041 --> 00:03:46,740 ‫Então isso foi fácil, vamos agora passar para o próximo 68 00:03:46,740 --> 00:03:49,810 ‫nível e falar sobre erros operacionais novamente. 69 00:03:49,810 --> 00:03:53,230 ‫Para isso, deixe-me abrir a classe de erro 70 00:03:53,230 --> 00:03:56,270 ‫do aplicativo que criamos e vamos lembrar 71 00:03:56,270 --> 00:03:57,870 ‫que marcamos todos 72 00:03:57,870 --> 00:04:02,313 ‫os erros que criamos, usando AppError operacional definido como verdadeiro. 73 00:04:03,721 --> 00:04:05,760 ‫Portanto, todos os erros 74 00:04:05,760 --> 00:04:07,873 ‫que criamos serão basicamente erros operacionais. 75 00:04:09,100 --> 00:04:11,950 ‫Na verdade, são apenas esses erros operacionais para 76 00:04:11,950 --> 00:04:14,540 ‫os quais queremos enviar a mensagem de 77 00:04:14,540 --> 00:04:15,703 ‫erro ao cliente. 78 00:04:16,720 --> 00:04:18,310 ‫Pelo menos em produção. 79 00:04:18,310 --> 00:04:21,900 ‫Portanto, quando, por outro lado, temos um erro de programação, ou 80 00:04:21,900 --> 00:04:23,880 ‫algum outro erro desconhecido que venha, 81 00:04:23,880 --> 00:04:26,500 ‫por exemplo, de um pacote de terceiros, 82 00:04:26,500 --> 00:04:29,930 ‫não queremos enviar nenhuma mensagem de erro sobre isso para 83 00:04:29,930 --> 00:04:31,864 ‫o cliente em produção. 84 00:04:31,864 --> 00:04:33,470 ‫E isso não adianta. 85 00:04:33,470 --> 00:04:37,340 ‫Esta é uma propriedade operacional aqui em nosso controlador de erro. 86 00:04:37,340 --> 00:04:40,090 ‫Lembra que eu já falei 87 00:04:40,090 --> 00:04:43,693 ‫sobre fazer isso quando criamos essa aula, certo? 88 00:04:45,580 --> 00:04:48,780 ‫Vamos agora enviar a produção de erros e fazer 89 00:04:49,730 --> 00:04:50,913 ‫esse teste. 90 00:04:52,270 --> 00:04:54,787 ‫Se houver erro. isOperational apenas 91 00:05:00,630 --> 00:05:05,053 ‫nesse caso, queremos realmente enviar esse erro aqui. 92 00:05:06,940 --> 00:05:08,113 ‫Em todos 93 00:05:10,070 --> 00:05:11,330 ‫os outros casos, simplesmente 94 00:05:11,330 --> 00:05:14,580 ‫enviaremos uma mensagem de erro muito genérica ao cliente. 95 00:05:14,580 --> 00:05:17,310 ‫Então, digamos, res. status e vamos simplesmente 96 00:05:19,400 --> 00:05:22,110 ‫enviar um código 500 genérico e, em 97 00:05:23,930 --> 00:05:25,123 ‫seguida, json. 98 00:05:28,120 --> 00:05:30,363 ‫O status será erro. 99 00:05:33,230 --> 00:05:36,660 ‫Então, vamos enviar uma mensagem genérica, dizendo que 100 00:05:38,200 --> 00:05:39,033 ‫algo 101 00:05:41,360 --> 00:05:42,573 ‫deu muito errado. 102 00:05:43,690 --> 00:05:46,983 ‫Portanto, fazer algo assim é um procedimento padrão. 103 00:05:48,420 --> 00:05:51,133 ‫Deixe-me comentar um pouco do código aqui. 104 00:05:54,530 --> 00:05:57,533 ‫Portanto, este é um erro operacional em que confiamos. 105 00:06:03,700 --> 00:06:06,200 ‫Aqui queremos enviar uma mensagem ao cliente. 106 00:06:06,200 --> 00:06:07,503 ‫Mas, neste caso 107 00:06:16,130 --> 00:06:17,973 ‫aqui, temos um erro desconhecido 108 00:06:19,080 --> 00:06:22,673 ‫e, portanto, não queremos vazar os detalhes para o cliente. 109 00:06:28,470 --> 00:06:31,380 ‫Então, vamos enviar esta mensagem para o cliente e 110 00:06:31,380 --> 00:06:33,070 ‫também para nós mesmos. 111 00:06:33,070 --> 00:06:35,340 ‫Para nós, desenvolvedores, queremos saber 112 00:06:35,340 --> 00:06:38,610 ‫se esse tipo de erro estranho, inesperado e 113 00:06:38,610 --> 00:06:41,993 ‫desconhecido ocorreu e vamos realmente registrá-lo no console. 114 00:06:49,100 --> 00:06:50,593 ‫Primeiro, registraremos o 115 00:06:56,702 --> 00:06:59,369 ‫erro e, em seguida, enviaremos uma mensagem genérica. 116 00:07:00,280 --> 00:07:03,270 ‫Digamos apenas console. erro, então isso é um pouco 117 00:07:03,270 --> 00:07:05,490 ‫como o console. log, mas 118 00:07:05,490 --> 00:07:07,870 ‫é realmente específico para erros e 119 00:07:07,870 --> 00:07:10,670 ‫acredito que a saída ficará um pouco diferente. 120 00:07:12,090 --> 00:07:15,670 ‫Portanto, erro, vamos adicionar alguns emojis aqui para torná-los visíveis em 121 00:07:15,670 --> 00:07:16,543 ‫nossos logs 122 00:07:17,950 --> 00:07:20,360 ‫e, em seguida, registrar o erro também. 123 00:07:20,360 --> 00:07:23,213 ‫Agora, existem bibliotecas de registro reais no mpm, que poderíamos 124 00:07:23,213 --> 00:07:24,550 ‫usar aqui em vez 125 00:07:24,550 --> 00:07:28,030 ‫de apenas ter este console simples. erro, mas apenas 126 00:07:28,030 --> 00:07:30,430 ‫registrar o erro no console o tornará 127 00:07:30,430 --> 00:07:32,220 ‫visível nos registros da plataforma 128 00:07:32,220 --> 00:07:34,363 ‫de hospedagem que você está usando. 129 00:07:35,486 --> 00:07:39,200 ‫Acho que por enquanto, neste tipo de aplicação simples, isso é 130 00:07:39,200 --> 00:07:40,073 ‫o suficiente. 131 00:07:41,110 --> 00:07:42,860 ‫Por exemplo, vamos usar o 132 00:07:42,860 --> 00:07:45,710 ‫Heroku no final do curso para implantar nosso aplicativo. 133 00:07:45,710 --> 00:07:47,600 ‫Então, quando um erro como 134 00:07:47,600 --> 00:07:49,970 ‫esse ocorrer, ele será registrado no console. 135 00:07:49,970 --> 00:07:54,180 ‫Na plataforma Heroku, então, temos acesso a esses logs. 136 00:07:54,180 --> 00:07:57,080 ‫Podemos continuar olhando esses registros e, aí, 137 00:07:57,080 --> 00:07:59,220 ‫encontraremos esses erros inesperados para 138 00:07:59,220 --> 00:08:00,670 ‫que possamos corrigi-los. 139 00:08:01,678 --> 00:08:04,470 ‫No momento, já estamos construindo aqui um 140 00:08:04,470 --> 00:08:07,000 ‫mecanismo sofisticado de tratamento de erros 141 00:08:07,000 --> 00:08:08,713 ‫do mundo real. 142 00:08:09,720 --> 00:08:13,240 ‫Então, vamos recapitular rapidamente o que acabamos de fazer aqui. 143 00:08:13,240 --> 00:08:16,380 ‫Estamos distinguindo entre erros no desenvolvimento e 144 00:08:16,380 --> 00:08:17,373 ‫na produção. 145 00:08:18,720 --> 00:08:21,420 ‫Quando estamos em produção, enviamos o erro 146 00:08:21,420 --> 00:08:22,970 ‫usando esta função aqui, 147 00:08:22,970 --> 00:08:26,050 ‫que então enviará o máximo de detalhes possível ao 148 00:08:26,050 --> 00:08:27,340 ‫cliente, para 149 00:08:27,340 --> 00:08:28,997 ‫que realmente obtenhamos todas as 150 00:08:28,997 --> 00:08:31,730 ‫informações a fim de nos livrarmos do bug. 151 00:08:31,730 --> 00:08:33,332 ‫Se for um 152 00:08:33,332 --> 00:08:35,670 ‫erro de programação ou operacional, 153 00:08:35,670 --> 00:08:39,083 ‫ainda queremos ver tudo o que está acontecendo. 154 00:08:40,670 --> 00:08:42,000 ‫Quando estamos 155 00:08:42,000 --> 00:08:44,330 ‫em produção, que é indiscutivelmente 156 00:08:44,330 --> 00:08:47,090 ‫a parte mais importante de nosso aplicativo, 157 00:08:47,090 --> 00:08:48,590 ‫distinguimos entre erros 158 00:08:48,590 --> 00:08:50,950 ‫operacionais, portanto, erros que conhecemos e 159 00:08:50,950 --> 00:08:54,163 ‫confiamos, e outros erros, que podem ser inesperados. 160 00:08:55,660 --> 00:08:58,800 ‫Se o erro for operacional, por exemplo, o usuário 161 00:08:58,800 --> 00:09:01,530 ‫tentou acessar uma rota que não existe, ou 162 00:09:01,530 --> 00:09:03,680 ‫tentou inserir dados inválidos, todos esses 163 00:09:03,680 --> 00:09:05,253 ‫são erros operacionais. 164 00:09:05,253 --> 00:09:08,130 ‫Então, podemos enviar mensagens de erro apropriadas, para que 165 00:09:08,130 --> 00:09:10,880 ‫o cliente saiba o que deu errado. 166 00:09:10,880 --> 00:09:13,820 ‫Por outro lado, temos esses erros 167 00:09:13,820 --> 00:09:16,380 ‫desconhecidos ou inesperados e, nesse 168 00:09:16,380 --> 00:09:19,420 ‫caso, dizemos muito simplesmente, algo deu errado. 169 00:09:19,420 --> 00:09:21,670 ‫Em seguida, registre o erro também em nosso 170 00:09:21,670 --> 00:09:24,433 ‫console, para que possamos saber o que aconteceu e podermos corrigi-lo. 171 00:09:25,510 --> 00:09:27,080 ‫Agora, para que isso funcione, 172 00:09:27,080 --> 00:09:29,160 ‫há algo muito, muito importante que 173 00:09:29,160 --> 00:09:30,193 ‫precisamos fazer. 174 00:09:31,040 --> 00:09:33,340 ‫Neste momento existem erros que 175 00:09:33,340 --> 00:09:37,550 ‫são, por exemplo, provenientes do MongoDB, que não marcamos como operacionais. 176 00:09:37,550 --> 00:09:40,970 ‫Nesse caso, eles seriam agora simplesmente tratados usando esta 177 00:09:40,970 --> 00:09:43,500 ‫mensagem de erro genérica aqui. 178 00:09:43,500 --> 00:09:45,330 ‫Por exemplo, um erro de validação. 179 00:09:45,330 --> 00:09:48,000 ‫No momento, esse é um erro que vem 180 00:09:48,000 --> 00:09:51,356 ‫do MongoDB e não de nossa própria classe de erro de aplicativo. 181 00:09:51,356 --> 00:09:54,869 ‫Não criamos esses erros por nós mesmos. 182 00:09:54,869 --> 00:09:58,800 ‫Novamente, eles agora não estão marcados como operacionais, mas é 183 00:09:58,800 --> 00:10:02,130 ‫claro que precisamos marcá-los como operacionais para que possamos 184 00:10:02,130 --> 00:10:04,680 ‫enviar a mensagem de erro apropriada 185 00:10:04,680 --> 00:10:06,400 ‫de volta ao cliente. 186 00:10:06,400 --> 00:10:08,360 ‫No exemplo que acabei de mencionar, os 187 00:10:08,360 --> 00:10:10,263 ‫dados de entrada são inválidos. 188 00:10:11,250 --> 00:10:14,230 ‫Existem dois ou três outros erros que precisamos 189 00:10:14,230 --> 00:10:15,793 ‫marcar como operacionais. 190 00:10:16,930 --> 00:10:18,020 ‫Então 191 00:10:19,410 --> 00:10:20,670 ‫faremos isso aqui. 192 00:10:20,670 --> 00:10:22,193 ‫Então, neste bloco 193 00:10:23,400 --> 00:10:25,850 ‫else, faremos isso nas próximas duas aulas.