1 00:00:01,150 --> 00:00:03,353 ‫Jonas: Dalam video ini, kami 2 00:00:03,353 --> 00:00:06,390 ‫akan menerapkan beberapa logika untuk mengirim pesan kesalahan 3 00:00:06,390 --> 00:00:09,173 ‫yang berbeda untuk lingkungan pengembangan dan produksi. 4 00:00:10,810 --> 00:00:14,490 ‫Jadi sekarang, kami mengirimkan pesan tanggapan yang sama di sini pada 5 00:00:14,490 --> 00:00:17,389 ‫dasarnya untuk semua orang, tidak peduli apakah kami sedang 6 00:00:17,389 --> 00:00:18,920 ‫dalam pengembangan atau produksi. 7 00:00:18,920 --> 00:00:21,690 ‫Tetapi idenya adalah bahwa dalam produksi, kami ingin 8 00:00:21,690 --> 00:00:23,810 ‫membocorkan sesedikit mungkin informasi tentang 9 00:00:23,810 --> 00:00:25,583 ‫kesalahan kami kepada klien. 10 00:00:26,420 --> 00:00:28,490 ‫Jadi dalam hal ini, kami hanya 11 00:00:28,490 --> 00:00:30,340 ‫ingin mengirim pesan yang 12 00:00:30,340 --> 00:00:33,070 ‫ramah manusia sehingga pengguna tahu apa yang salah. 13 00:00:33,070 --> 00:00:34,858 ‫Di sisi lain, saat 14 00:00:34,858 --> 00:00:37,700 ‫pengembangan tertulis, kami ingin mendapatkan informasi sebanyak mungkin 15 00:00:37,700 --> 00:00:40,390 ‫tentang kesalahan yang terjadi, dan kami ingin itu 16 00:00:40,390 --> 00:00:42,950 ‫benar dalam pesan kesalahan yang muncul kembali. 17 00:00:42,950 --> 00:00:45,520 ‫Jadi kita bisa mencatat informasi itu juga ke 18 00:00:45,520 --> 00:00:48,340 ‫konsol, tapi menurut saya jauh lebih berguna untuk memiliki 19 00:00:48,340 --> 00:00:51,150 ‫informasi itu langsung di tukang pos, dalam hal ini. 20 00:00:51,150 --> 00:00:53,660 ‫Jadi, kita sudah tahu bagaimana membedakan 21 00:00:53,660 --> 00:00:56,010 ‫antara lingkungan pengembangan dan produksi. 22 00:00:56,870 --> 00:00:58,213 ‫Jadi, mari kita lakukan itu. 23 00:00:59,130 --> 00:00:59,963 ‫Jadi 24 00:01:01,630 --> 00:01:05,010 ‫jika proses. lingkungan node_env sama 25 00:01:06,510 --> 00:01:08,970 ‫dengan pengembangan maka kami ingin mengirim 26 00:01:11,810 --> 00:01:13,780 ‫satu jenis kesalahan dan 27 00:01:15,530 --> 00:01:17,060 ‫jika kami dalam 28 00:01:17,060 --> 00:01:21,020 ‫produksi, maka kami ingin mengirim kesalahan yang lebih sederhana. 29 00:01:21,020 --> 00:01:21,853 ‫Baik. 30 00:01:24,290 --> 00:01:26,913 ‫Jadi sama dengan produksi. 31 00:01:30,160 --> 00:01:33,343 ‫Baiklah, jadi mari kita ambil yang ini, jadi 32 00:01:34,390 --> 00:01:36,380 ‫sekali lagi, ketika pengembangan 33 00:01:36,380 --> 00:01:39,850 ‫tertulis, kami ingin mendapatkan semua informasi yang kami bisa. 34 00:01:39,850 --> 00:01:43,763 ‫Jadi itu juga mencetak atau merespons dengan tumpukan kesalahan di sini. 35 00:01:48,620 --> 00:01:52,300 ‫Jadi salah. tumpukan, dan kemudian mari 36 00:01:52,300 --> 00:01:54,483 ‫kita juga mencetak seluruh kesalahan juga. 37 00:01:56,240 --> 00:02:00,830 ‫Katakanlah kesalahan, dan atur ke oke. 38 00:02:00,830 --> 00:02:02,003 ‫Kemudian di sisi 39 00:02:03,030 --> 00:02:05,183 ‫lain, mari kita salin ini lagi. 40 00:02:06,040 --> 00:02:09,350 ‫Saat kita dalam produksi, kita tidak menginginkan tumpukan 41 00:02:09,350 --> 00:02:12,493 ‫dan kita juga tidak menginginkan kesalahan total. 42 00:02:13,490 --> 00:02:16,113 ‫Jadi benar-benar hanya status dan pesannya. 43 00:02:19,190 --> 00:02:20,933 ‫Ini di sini terlihat 44 00:02:21,930 --> 00:02:24,550 ‫agak berantakan, jadi mari kita ekspor ini ke 45 00:02:24,550 --> 00:02:27,440 ‫dalam fungsinya sendiri dan juga karena kita sebenarnya akan 46 00:02:27,440 --> 00:02:30,719 ‫menambahkan lebih banyak kode di sini, di cabang lain ini. 47 00:02:30,719 --> 00:02:33,730 ‫Ini sedikit lebih bersih untuk memiliki ini ke dalam fungsi 48 00:02:33,730 --> 00:02:35,180 ‫mereka sendiri yang terpisah. 49 00:02:36,500 --> 00:02:37,550 ‫Jadi katakanlah 50 00:02:39,540 --> 00:02:41,480 ‫kesalahan pengiriman const untuk 51 00:02:43,930 --> 00:02:46,470 ‫dev dan fungsi itu kemudian harus 52 00:02:46,470 --> 00:02:49,903 ‫menerima kesalahan, dan kami juga harus meneruskan subjek respons. 53 00:02:51,990 --> 00:02:54,930 ‫Itu karena begitulah cara kami sebenarnya 54 00:02:54,930 --> 00:02:57,223 ‫dapat mengirim tanggapan, bukan? 55 00:02:58,360 --> 00:03:02,090 ‫Jadi kita membutuhkan subjek respon untuk dapat menjalankan kode 56 00:03:02,090 --> 00:03:02,933 ‫ini. 57 00:03:04,080 --> 00:03:06,510 ‫Di sini kita hanya akan 58 00:03:07,410 --> 00:03:08,990 ‫memanggil pengembang kesalahan 59 00:03:09,890 --> 00:03:11,263 ‫kirim 60 00:03:11,263 --> 00:03:13,073 ‫dengan kesalahan, dan responsnya. 61 00:03:14,270 --> 00:03:15,483 ‫Kemudian di 62 00:03:17,030 --> 00:03:18,030 ‫sini, 63 00:03:18,030 --> 00:03:21,783 ‫kita akan mengirimkan produksi kesalahan, argumen 64 00:03:24,830 --> 00:03:26,253 ‫yang sama. 65 00:03:36,300 --> 00:03:37,500 ‫Dan kemudian di sini, sama. 66 00:03:43,041 --> 00:03:46,740 ‫Jadi itu mudah, sekarang mari kita bawa ke tingkat 67 00:03:46,740 --> 00:03:49,810 ‫berikutnya dan berbicara tentang kesalahan operasional lagi. 68 00:03:49,810 --> 00:03:53,230 ‫Untuk itu, izinkan saya membuka kelas kesalahan aplikasi 69 00:03:53,230 --> 00:03:56,270 ‫yang kita buat, dan mari kita ingat 70 00:03:56,270 --> 00:03:57,870 ‫bahwa kita menandai 71 00:03:57,870 --> 00:04:02,313 ‫semua kesalahan yang kita buat, menggunakan AppError operasional disetel ke true. 72 00:04:03,721 --> 00:04:05,760 ‫Jadi semua kesalahan yang kita 73 00:04:05,760 --> 00:04:07,873 ‫buat sendiri pada dasarnya adalah kesalahan operasional. 74 00:04:09,100 --> 00:04:11,950 ‫Faktanya, hanya kesalahan operasional ini yang 75 00:04:11,950 --> 00:04:14,540 ‫ingin kami kirimkan pesan kesalahannya 76 00:04:14,540 --> 00:04:15,703 ‫ke klien. 77 00:04:16,720 --> 00:04:18,310 ‫Setidaknya dalam produksi. 78 00:04:18,310 --> 00:04:21,900 ‫Jadi ketika kami, di sisi lain, memiliki kesalahan pemrograman, atau 79 00:04:21,900 --> 00:04:23,880 ‫kesalahan lain yang tidak diketahui 80 00:04:23,880 --> 00:04:26,500 ‫yang datang, misalnya, dari paket pihak ketiga, 81 00:04:26,500 --> 00:04:29,930 ‫kami tidak ingin mengirim pesan kesalahan tentang itu ke 82 00:04:29,930 --> 00:04:31,864 ‫klien dalam produksi. 83 00:04:31,864 --> 00:04:33,470 ‫Dan jadi itu tidak ada gunanya. 84 00:04:33,470 --> 00:04:37,340 ‫Ini adalah properti operasional di sini di pengontrol kesalahan kami. 85 00:04:37,340 --> 00:04:40,090 ‫Ingat bagaimana saya sudah berbicara tentang 86 00:04:40,090 --> 00:04:43,693 ‫melakukan itu pada saat kita membuat kelas ini, kan? 87 00:04:45,580 --> 00:04:48,780 ‫Mari sekarang datang ke sini untuk mengirim produksi kesalahan dan 88 00:04:49,730 --> 00:04:50,913 ‫melakukan tes itu. 89 00:04:52,270 --> 00:04:54,787 ‫Jika kesalahan. isOperational hanya 90 00:05:00,630 --> 00:05:05,053 ‫dalam hal ini kami benar-benar ingin mengirim kesalahan ini ke sini. 91 00:05:06,940 --> 00:05:08,113 ‫Dalam semua 92 00:05:10,070 --> 00:05:11,330 ‫kasus lain, kami hanya 93 00:05:11,330 --> 00:05:14,580 ‫akan mengirim pesan kesalahan yang sangat umum ke klien. 94 00:05:14,580 --> 00:05:17,310 ‫Jadi katakanlah, res. status dan kami 95 00:05:19,400 --> 00:05:22,110 ‫hanya akan mengirim kode 500 generik dan 96 00:05:23,930 --> 00:05:25,123 ‫kemudian json. 97 00:05:28,120 --> 00:05:30,363 ‫Statusnya akan menjadi kesalahan. 98 00:05:33,230 --> 00:05:36,660 ‫Kalau begitu mari kita kirim pesan umum, 99 00:05:38,200 --> 00:05:39,033 ‫mengatakan 100 00:05:41,360 --> 00:05:42,573 ‫ada yang salah. 101 00:05:43,690 --> 00:05:46,983 ‫Jadi melakukan hal seperti ini adalah prosedur yang sangat standar. 102 00:05:48,420 --> 00:05:51,133 ‫Biarkan saya benar-benar mengomentari beberapa kode di sini. 103 00:05:54,530 --> 00:05:57,533 ‫Jadi ini adalah kesalahan operasional yang kami percaya. 104 00:06:03,700 --> 00:06:06,200 ‫Di sini kami ingin mengirim pesan ke klien. 105 00:06:06,200 --> 00:06:07,503 ‫Tetapi dalam kasus 106 00:06:16,130 --> 00:06:17,973 ‫ini di sini, kami memiliki kesalahan 107 00:06:19,080 --> 00:06:22,673 ‫yang tidak diketahui, jadi kami tidak ingin membocorkan detailnya ke klien. 108 00:06:28,470 --> 00:06:31,380 ‫Jadi kami hanya akan mengirim pesan ini ke klien, dan 109 00:06:31,380 --> 00:06:33,070 ‫juga untuk diri kami sendiri. 110 00:06:33,070 --> 00:06:35,340 ‫Bagi kami pengembang, kami ingin 111 00:06:35,340 --> 00:06:38,610 ‫tahu bahwa kesalahan aneh, tak terduga, dan tidak diketahui 112 00:06:38,610 --> 00:06:41,993 ‫semacam ini terjadi dan kami benar-benar akan mencatatnya ke konsol. 113 00:06:49,100 --> 00:06:50,593 ‫Kami akan mencatat 114 00:06:56,702 --> 00:06:59,369 ‫kesalahan terlebih dahulu, lalu mengirim pesan umum. 115 00:07:00,280 --> 00:07:03,270 ‫Katakan saja, konsol. error, jadi ini agak 116 00:07:03,270 --> 00:07:05,490 ‫mirip console. log, tetapi 117 00:07:05,490 --> 00:07:07,870 ‫ini sangat spesifik untuk kesalahan dan 118 00:07:07,870 --> 00:07:10,670 ‫saya yakin hasilnya akan terlihat sedikit berbeda. 119 00:07:12,090 --> 00:07:15,670 ‫Jadi kesalahan, mari tambahkan beberapa emoji di sini untuk membuatnya 120 00:07:15,670 --> 00:07:16,543 ‫terlihat di 121 00:07:17,950 --> 00:07:20,360 ‫log kita, lalu catat kesalahannya juga. 122 00:07:20,360 --> 00:07:23,213 ‫Sekarang ada perpustakaan logging nyata di mpm, yang bisa kita 123 00:07:23,213 --> 00:07:24,550 ‫gunakan di sini 124 00:07:24,550 --> 00:07:28,030 ‫daripada hanya memiliki konsol sederhana ini. kesalahan, tetapi hanya 125 00:07:28,030 --> 00:07:30,430 ‫mencatat kesalahan ke konsol akan membuatnya 126 00:07:30,430 --> 00:07:32,220 ‫terlihat di log pada 127 00:07:32,220 --> 00:07:34,363 ‫platform hosting yang Anda gunakan. 128 00:07:35,486 --> 00:07:39,200 ‫Saya pikir untuk saat ini, dalam aplikasi sederhana semacam ini, itu 129 00:07:39,200 --> 00:07:40,073 ‫sudah cukup. 130 00:07:41,110 --> 00:07:42,860 ‫Misalnya, kita akan menggunakan 131 00:07:42,860 --> 00:07:45,710 ‫Heroku di akhir kursus untuk men-deploy aplikasi kita. 132 00:07:45,710 --> 00:07:47,600 ‫Kemudian ketika error seperti 133 00:07:47,600 --> 00:07:49,970 ‫ini terjadi, maka akan login ke console. 134 00:07:49,970 --> 00:07:54,180 ‫Di platform Heroku, kami kemudian memiliki akses ke log ini. 135 00:07:54,180 --> 00:07:57,080 ‫Kami dapat terus melihat log ini, dan kemudian di sana 136 00:07:57,080 --> 00:07:59,220 ‫kami akan menemukan kesalahan tak terduga ini 137 00:07:59,220 --> 00:08:00,670 ‫sehingga kami dapat memperbaikinya. 138 00:08:01,678 --> 00:08:04,470 ‫Saat ini, kami sebenarnya sudah membangun 139 00:08:04,470 --> 00:08:07,000 ‫mekanisme penanganan kesalahan yang canggih dan 140 00:08:07,000 --> 00:08:08,713 ‫nyata di sini. 141 00:08:09,720 --> 00:08:13,240 ‫Jadi mari kita cepat rekap apa yang baru saja kita lakukan di sini. 142 00:08:13,240 --> 00:08:16,380 ‫Kami membedakan antara kesalahan dalam pengembangan dan 143 00:08:16,380 --> 00:08:17,373 ‫produksi. 144 00:08:18,720 --> 00:08:21,420 ‫Saat kami dalam produksi, kami mengirim 145 00:08:21,420 --> 00:08:22,970 ‫kesalahan menggunakan fungsi 146 00:08:22,970 --> 00:08:26,050 ‫ini di sini, yang kemudian akan mengirimkan detail 147 00:08:26,050 --> 00:08:27,340 ‫sebanyak mungkin 148 00:08:27,340 --> 00:08:28,997 ‫ke klien, sehingga kami 149 00:08:28,997 --> 00:08:31,730 ‫benar-benar mendapatkan semua informasi untuk menghilangkan bug. 150 00:08:31,730 --> 00:08:33,332 ‫Jika itu adalah kesalahan 151 00:08:33,332 --> 00:08:35,670 ‫pemrograman, atau jika itu adalah kesalahan operasional, 152 00:08:35,670 --> 00:08:39,083 ‫maka kami masih benar-benar ingin melihat apa pun yang terjadi. 153 00:08:40,670 --> 00:08:42,000 ‫Ketika kita sedang 154 00:08:42,000 --> 00:08:44,330 ‫dalam produksi, yang bisa dibilang merupakan 155 00:08:44,330 --> 00:08:47,090 ‫bagian terpenting dari aplikasi kita, maka kita 156 00:08:47,090 --> 00:08:48,590 ‫membedakan antara kesalahan operasional, 157 00:08:48,590 --> 00:08:50,950 ‫jadi kesalahan yang kita ketahui dan 158 00:08:50,950 --> 00:08:54,163 ‫percayai, dan kesalahan lainnya, yang mungkin agak tidak terduga. 159 00:08:55,660 --> 00:08:58,800 ‫Jika kesalahan operasional, jadi misalnya pengguna mencoba mengakses 160 00:08:58,800 --> 00:09:01,530 ‫rute yang tidak ada, atau mencoba memasukkan 161 00:09:01,530 --> 00:09:03,680 ‫data yang tidak valid, semua ini 162 00:09:03,680 --> 00:09:05,253 ‫adalah kesalahan operasional. 163 00:09:05,253 --> 00:09:08,130 ‫Kemudian kami dapat mengirim pesan kesalahan yang sesuai, 164 00:09:08,130 --> 00:09:10,880 ‫agar klien mengetahui apa yang salah. 165 00:09:10,880 --> 00:09:13,820 ‫Di sisi lain, kami memiliki kesalahan yang tidak diketahui ini, 166 00:09:13,820 --> 00:09:16,380 ‫atau kesalahan yang tidak terduga, dan dalam 167 00:09:16,380 --> 00:09:19,420 ‫hal ini, kami dengan mudah mengatakan, ada yang tidak beres. 168 00:09:19,420 --> 00:09:21,670 ‫Kemudian log kesalahan juga ke konsol kami, 169 00:09:21,670 --> 00:09:24,433 ‫sehingga kami tahu itu terjadi dan kemudian dapat memperbaikinya. 170 00:09:25,510 --> 00:09:27,080 ‫Sekarang agar ini berhasil, ada 171 00:09:27,080 --> 00:09:29,160 ‫sesuatu yang sangat, sangat penting yang perlu 172 00:09:29,160 --> 00:09:30,193 ‫kita lakukan. 173 00:09:31,040 --> 00:09:33,340 ‫Saat ini ada kesalahan yang, 174 00:09:33,340 --> 00:09:37,550 ‫misalnya, berasal dari MongoDB, yang tidak kami tandai sebagai operasional. 175 00:09:37,550 --> 00:09:40,970 ‫Dalam hal ini, mereka sekarang hanya akan ditangani menggunakan 176 00:09:40,970 --> 00:09:43,500 ‫pesan kesalahan umum ini di sini. 177 00:09:43,500 --> 00:09:45,330 ‫Misalnya, kesalahan validasi. 178 00:09:45,330 --> 00:09:48,000 ‫Saat ini, itu adalah kesalahan yang berasal 179 00:09:48,000 --> 00:09:51,356 ‫dari MongoDB dan bukan dari kelas kesalahan aplikasi kita sendiri. 180 00:09:51,356 --> 00:09:54,869 ‫Kami tidak membuat kesalahan ini sendiri. 181 00:09:54,869 --> 00:09:58,800 ‫Sekali lagi, mereka saat ini tidak ditandai sebagai operasional, tetapi 182 00:09:58,800 --> 00:10:02,130 ‫tentu saja kami perlu menandainya sebagai operasional sehingga 183 00:10:02,130 --> 00:10:04,680 ‫kami dapat mengirim kembali pesan kesalahan 184 00:10:04,680 --> 00:10:06,400 ‫yang sesuai ke klien. 185 00:10:06,400 --> 00:10:08,360 ‫Dalam contoh yang baru saja saya sebutkan, 186 00:10:08,360 --> 00:10:10,263 ‫bahwa data input tidak valid. 187 00:10:11,250 --> 00:10:14,230 ‫Ada dua atau tiga kesalahan lain yang perlu kita 188 00:10:14,230 --> 00:10:15,793 ‫tandai sebagai operasional sendiri. 189 00:10:16,930 --> 00:10:18,020 ‫Jadi kita 190 00:10:19,410 --> 00:10:20,670 ‫akan melakukannya di sini. 191 00:10:20,670 --> 00:10:22,193 ‫Jadi di blok lain 192 00:10:23,400 --> 00:10:25,850 ‫ini, kita akan melakukannya selama beberapa kuliah berikutnya.