‫Jonas: Dalam video ini, kami
‫akan menerapkan beberapa logika untuk mengirim pesan kesalahan
‫yang berbeda untuk lingkungan pengembangan dan produksi.
‫Jadi sekarang, kami mengirimkan pesan tanggapan yang sama di sini pada
‫dasarnya untuk semua orang, tidak peduli apakah kami sedang
‫dalam pengembangan atau produksi.
‫Tetapi idenya adalah bahwa dalam produksi, kami ingin
‫membocorkan sesedikit mungkin informasi tentang
‫kesalahan kami kepada klien.
‫Jadi dalam hal ini, kami hanya
‫ingin mengirim pesan yang
‫ramah manusia sehingga pengguna tahu apa yang salah.
‫Di sisi lain, saat
‫pengembangan tertulis, kami ingin mendapatkan informasi sebanyak mungkin
‫tentang kesalahan yang terjadi, dan kami ingin itu
‫benar dalam pesan kesalahan yang muncul kembali.
‫Jadi kita bisa mencatat informasi itu juga ke
‫konsol, tapi menurut saya jauh lebih berguna untuk memiliki
‫informasi itu langsung di tukang pos, dalam hal ini.
‫Jadi, kita sudah tahu bagaimana membedakan
‫antara lingkungan pengembangan dan produksi.
‫Jadi, mari kita lakukan itu.
‫Jadi
‫jika proses. lingkungan node_env sama
‫dengan pengembangan maka kami ingin mengirim
‫satu jenis kesalahan dan
‫jika kami dalam
‫produksi, maka kami ingin mengirim kesalahan yang lebih sederhana.
‫Baik.
‫Jadi sama dengan produksi.
‫Baiklah, jadi mari kita ambil yang ini, jadi
‫sekali lagi, ketika pengembangan
‫tertulis, kami ingin mendapatkan semua informasi yang kami bisa.
‫Jadi itu juga mencetak atau merespons dengan tumpukan kesalahan di sini.
‫Jadi salah. tumpukan, dan kemudian mari
‫kita juga mencetak seluruh kesalahan juga.
‫Katakanlah kesalahan, dan atur ke oke.
‫Kemudian di sisi
‫lain, mari kita salin ini lagi.
‫Saat kita dalam produksi, kita tidak menginginkan tumpukan
‫dan kita juga tidak menginginkan kesalahan total.
‫Jadi benar-benar hanya status dan pesannya.
‫Ini di sini terlihat
‫agak berantakan, jadi mari kita ekspor ini ke
‫dalam fungsinya sendiri dan juga karena kita sebenarnya akan
‫menambahkan lebih banyak kode di sini, di cabang lain ini.
‫Ini sedikit lebih bersih untuk memiliki ini ke dalam fungsi
‫mereka sendiri yang terpisah.
‫Jadi katakanlah
‫kesalahan pengiriman const untuk
‫dev dan fungsi itu kemudian harus
‫menerima kesalahan, dan kami juga harus meneruskan subjek respons.
‫Itu karena begitulah cara kami sebenarnya
‫dapat mengirim tanggapan, bukan?
‫Jadi kita membutuhkan subjek respon untuk dapat menjalankan kode
‫ini.
‫Di sini kita hanya akan
‫memanggil pengembang kesalahan
‫kirim
‫dengan kesalahan, dan responsnya.
‫Kemudian di
‫sini,
‫kita akan mengirimkan produksi kesalahan, argumen
‫yang sama.
‫Dan kemudian di sini, sama.
‫Jadi itu mudah, sekarang mari kita bawa ke tingkat
‫berikutnya dan berbicara tentang kesalahan operasional lagi.
‫Untuk itu, izinkan saya membuka kelas kesalahan aplikasi
‫yang kita buat, dan mari kita ingat
‫bahwa kita menandai
‫semua kesalahan yang kita buat, menggunakan AppError operasional disetel ke true.
‫Jadi semua kesalahan yang kita
‫buat sendiri pada dasarnya adalah kesalahan operasional.
‫Faktanya, hanya kesalahan operasional ini yang
‫ingin kami kirimkan pesan kesalahannya
‫ke klien.
‫Setidaknya dalam produksi.
‫Jadi ketika kami, di sisi lain, memiliki kesalahan pemrograman, atau
‫kesalahan lain yang tidak diketahui
‫yang datang, misalnya, dari paket pihak ketiga,
‫kami tidak ingin mengirim pesan kesalahan tentang itu ke
‫klien dalam produksi.
‫Dan jadi itu tidak ada gunanya.
‫Ini adalah properti operasional di sini di pengontrol kesalahan kami.
‫Ingat bagaimana saya sudah berbicara tentang
‫melakukan itu pada saat kita membuat kelas ini, kan?
‫Mari sekarang datang ke sini untuk mengirim produksi kesalahan dan
‫melakukan tes itu.
‫Jika kesalahan. isOperational hanya
‫dalam hal ini kami benar-benar ingin mengirim kesalahan ini ke sini.
‫Dalam semua
‫kasus lain, kami hanya
‫akan mengirim pesan kesalahan yang sangat umum ke klien.
‫Jadi katakanlah, res. status dan kami
‫hanya akan mengirim kode 500 generik dan
‫kemudian json.
‫Statusnya akan menjadi kesalahan.
‫Kalau begitu mari kita kirim pesan umum,
‫mengatakan
‫ada yang salah.
‫Jadi melakukan hal seperti ini adalah prosedur yang sangat standar.
‫Biarkan saya benar-benar mengomentari beberapa kode di sini.
‫Jadi ini adalah kesalahan operasional yang kami percaya.
‫Di sini kami ingin mengirim pesan ke klien.
‫Tetapi dalam kasus
‫ini di sini, kami memiliki kesalahan
‫yang tidak diketahui, jadi kami tidak ingin membocorkan detailnya ke klien.
‫Jadi kami hanya akan mengirim pesan ini ke klien, dan
‫juga untuk diri kami sendiri.
‫Bagi kami pengembang, kami ingin
‫tahu bahwa kesalahan aneh, tak terduga, dan tidak diketahui
‫semacam ini terjadi dan kami benar-benar akan mencatatnya ke konsol.
‫Kami akan mencatat
‫kesalahan terlebih dahulu, lalu mengirim pesan umum.
‫Katakan saja, konsol. error, jadi ini agak
‫mirip console. log, tetapi
‫ini sangat spesifik untuk kesalahan dan
‫saya yakin hasilnya akan terlihat sedikit berbeda.
‫Jadi kesalahan, mari tambahkan beberapa emoji di sini untuk membuatnya
‫terlihat di
‫log kita, lalu catat kesalahannya juga.
‫Sekarang ada perpustakaan logging nyata di mpm, yang bisa kita
‫gunakan di sini
‫daripada hanya memiliki konsol sederhana ini. kesalahan, tetapi hanya
‫mencatat kesalahan ke konsol akan membuatnya
‫terlihat di log pada
‫platform hosting yang Anda gunakan.
‫Saya pikir untuk saat ini, dalam aplikasi sederhana semacam ini, itu
‫sudah cukup.
‫Misalnya, kita akan menggunakan
‫Heroku di akhir kursus untuk men-deploy aplikasi kita.
‫Kemudian ketika error seperti
‫ini terjadi, maka akan login ke console.
‫Di platform Heroku, kami kemudian memiliki akses ke log ini.
‫Kami dapat terus melihat log ini, dan kemudian di sana
‫kami akan menemukan kesalahan tak terduga ini
‫sehingga kami dapat memperbaikinya.
‫Saat ini, kami sebenarnya sudah membangun
‫mekanisme penanganan kesalahan yang canggih dan
‫nyata di sini.
‫Jadi mari kita cepat rekap apa yang baru saja kita lakukan di sini.
‫Kami membedakan antara kesalahan dalam pengembangan dan
‫produksi.
‫Saat kami dalam produksi, kami mengirim
‫kesalahan menggunakan fungsi
‫ini di sini, yang kemudian akan mengirimkan detail
‫sebanyak mungkin
‫ke klien, sehingga kami
‫benar-benar mendapatkan semua informasi untuk menghilangkan bug.
‫Jika itu adalah kesalahan
‫pemrograman, atau jika itu adalah kesalahan operasional,
‫maka kami masih benar-benar ingin melihat apa pun yang terjadi.
‫Ketika kita sedang
‫dalam produksi, yang bisa dibilang merupakan
‫bagian terpenting dari aplikasi kita, maka kita
‫membedakan antara kesalahan operasional,
‫jadi kesalahan yang kita ketahui dan
‫percayai, dan kesalahan lainnya, yang mungkin agak tidak terduga.
‫Jika kesalahan operasional, jadi misalnya pengguna mencoba mengakses
‫rute yang tidak ada, atau mencoba memasukkan
‫data yang tidak valid, semua ini
‫adalah kesalahan operasional.
‫Kemudian kami dapat mengirim pesan kesalahan yang sesuai,
‫agar klien mengetahui apa yang salah.
‫Di sisi lain, kami memiliki kesalahan yang tidak diketahui ini,
‫atau kesalahan yang tidak terduga, dan dalam
‫hal ini, kami dengan mudah mengatakan, ada yang tidak beres.
‫Kemudian log kesalahan juga ke konsol kami,
‫sehingga kami tahu itu terjadi dan kemudian dapat memperbaikinya.
‫Sekarang agar ini berhasil, ada
‫sesuatu yang sangat, sangat penting yang perlu
‫kita lakukan.
‫Saat ini ada kesalahan yang,
‫misalnya, berasal dari MongoDB, yang tidak kami tandai sebagai operasional.
‫Dalam hal ini, mereka sekarang hanya akan ditangani menggunakan
‫pesan kesalahan umum ini di sini.
‫Misalnya, kesalahan validasi.
‫Saat ini, itu adalah kesalahan yang berasal
‫dari MongoDB dan bukan dari kelas kesalahan aplikasi kita sendiri.
‫Kami tidak membuat kesalahan ini sendiri.
‫Sekali lagi, mereka saat ini tidak ditandai sebagai operasional, tetapi
‫tentu saja kami perlu menandainya sebagai operasional sehingga
‫kami dapat mengirim kembali pesan kesalahan
‫yang sesuai ke klien.
‫Dalam contoh yang baru saja saya sebutkan,
‫bahwa data input tidak valid.
‫Ada dua atau tiga kesalahan lain yang perlu kita
‫tandai sebagai operasional sendiri.
‫Jadi kita
‫akan melakukannya di sini.
‫Jadi di blok lain
‫ini, kita akan melakukannya selama beberapa kuliah berikutnya.