1
00:00:01,120 --> 00:00:03,120
‫Instruktur: Dalam video ini, mari kita bicara tentang

2
00:00:03,120 --> 00:00:06,770
‫sesuatu yang kita miliki di node.js. js memanggil penolakan yang tidak

3
00:00:06,770 --> 00:00:09,543
‫tertangani dan kemudian mempelajari bagaimana kita dapat menanganinya.

4
00:00:10,970 --> 00:00:14,400
‫Jadi pada titik ini, kami telah berhasil

5
00:00:14,400 --> 00:00:16,330
‫menangani kesalahan dalam

6
00:00:16,330 --> 00:00:19,970
‫aplikasi ekspres kami dengan meneruskan kesalahan asinkron operasional

7
00:00:19,970 --> 00:00:22,410
‫ke middleware penanganan kesalahan global.

8
00:00:22,410 --> 00:00:26,200
‫Ini, kemudian mengirim pesan kesalahan yang relevan

9
00:00:26,200 --> 00:00:30,510
‫kembali ke klien tergantung pada jenis kesalahan yang terjadi, bukan?

10
00:00:30,510 --> 00:00:34,730
‫Namun, mungkin juga terjadi kesalahan di luar ekspres dan contoh

11
00:00:34,730 --> 00:00:38,520
‫yang baik untuk itu dalam aplikasi kita saat ini

12
00:00:38,520 --> 00:00:40,810
‫adalah koneksi database mongodb.

13
00:00:40,810 --> 00:00:43,700
‫Jadi bayangkan database sedang down karena suatu alasan atau

14
00:00:43,700 --> 00:00:46,000
‫karena alasan tertentu, kita tidak bisa login.

15
00:00:46,000 --> 00:00:47,920
‫Dan dalam hal ini, ada kesalahan

16
00:00:47,920 --> 00:00:49,610
‫yang harus kita tangani juga.

17
00:00:49,610 --> 00:00:52,800
‫Tapi itu tidak terjadi di dalam aplikasi ekspres kita

18
00:00:52,800 --> 00:00:55,810
‫dan, tentu saja, pengendali kesalahan yang kita terapkan

19
00:00:55,810 --> 00:00:58,560
‫tidak akan menangkap kesalahan ini, bukan?

20
00:00:58,560 --> 00:01:01,790
‫Jadi hanya untuk menguji apa yang terjadi, mari

21
00:01:01,790 --> 00:01:05,110
‫kita lanjutkan dan ubah kata sandi mongodb kita, oke?

22
00:01:05,110 --> 00:01:06,960
‫Karena dengan begitu, kita

23
00:01:06,960 --> 00:01:10,180
‫tidak akan bisa terhubung ke database, kan?

24
00:01:10,180 --> 00:01:13,110
‫Jadi kita kemudian harus mendapatkan semacam kesalahan, dan jadi

25
00:01:13,110 --> 00:01:15,510
‫mari kita pergi ke sini ke file

26
00:01:15,510 --> 00:01:18,633
‫server kita dan menyimpannya untuk memuat ulang server kita, mari

27
00:01:20,710 --> 00:01:23,040
‫kita tingkatkan di sini, dan memang,

28
00:01:23,040 --> 00:01:26,120
‫di sini kita memiliki penolakan janji yang tidak tertangani.

29
00:01:26,120 --> 00:01:29,510
‫Dan itulah sebenarnya topik video ini.

30
00:01:29,510 --> 00:01:33,600
‫Jadi, penolakan janji yang tidak tertangani berarti bahwa di suatu

31
00:01:33,600 --> 00:01:37,140
‫tempat dalam kode kita, ada janji yang ditolak.

32
00:01:37,140 --> 00:01:41,270
‫Tapi penolakan itu belum ditangani di mana pun, oke?

33
00:01:41,270 --> 00:01:44,920
‫Dan di bawah sini, Anda juga melihat peringatan penghentian yang

34
00:01:44,920 --> 00:01:48,008
‫mengatakan bahwa di masa depan penolakan yang

35
00:01:48,008 --> 00:01:51,710
‫tidak tertangani hanya akan keluar dari program simpul yang sedang

36
00:01:51,710 --> 00:01:54,940
‫berjalan, yang mungkin tidak selalu sesuai keinginan Anda, oke?

37
00:01:54,940 --> 00:01:57,450
‫Jadi mari kita perbaiki masalah ini

38
00:01:57,450 --> 00:02:00,000
‫dan singkirkan penolakan janji yang tidak tertangani ini.

39
00:02:00,000 --> 00:02:01,910
‫Nah, dalam contoh sederhana ini,

40
00:02:01,910 --> 00:02:03,270
‫sebenarnya cukup

41
00:02:03,270 --> 00:02:05,770
‫mudah untuk menangani penolakan itu, bukan?

42
00:02:05,770 --> 00:02:08,060
‫Yang harus kita lakukan adalah datang ke

43
00:02:08,060 --> 00:02:11,550
‫sini ke bagian kode ini di mana koneksi kita benar-benar selesai

44
00:02:11,550 --> 00:02:14,100
‫dan kemudian, tambahkan catch handler di sana, bukan?

45
00:02:14,100 --> 00:02:16,580
‫Jadi sedikit seperti ini, dan kemudian di sini,

46
00:02:16,580 --> 00:02:18,640
‫kita bisa menangani penolakan itu

47
00:02:18,640 --> 00:02:20,970
‫dan tidak akan lagi mendapatkan kesalahan ini.

48
00:02:20,970 --> 00:02:22,820
‫Biarkan saya dengan cepat menunjukkan itu kepada Anda.

49
00:02:29,905 --> 00:02:31,960
‫Jadi coba lagi.

50
00:02:31,960 --> 00:02:35,630
‫Dan sekarang, Anda mendapatkan kesalahan yang tentu saja, hasil dari

51
00:02:35,630 --> 00:02:37,950
‫log ini di sini, tetapi

52
00:02:37,950 --> 00:02:41,010
‫tentu saja, kami tidak mendapatkan penolakan janji yang

53
00:02:41,010 --> 00:02:45,060
‫tidak tertangani, sekali lagi, karena kami benar-benar menanganinya di sini, oke?

54
00:02:45,060 --> 00:02:48,580
‫Jadi ini akan berhasil, tentu saja, tetapi saya benar-benar ingin menunjukkan

55
00:02:48,580 --> 00:02:51,720
‫kepada Anda bagaimana secara global menangani janji yang ditolak

56
00:02:51,720 --> 00:02:54,680
‫yang tidak ditangani, karena dalam aplikasi yang lebih besar,

57
00:02:54,680 --> 00:02:57,860
‫bisa menjadi sedikit lebih sulit untuk selalu melacak semua janji

58
00:02:57,860 --> 00:03:00,590
‫yang mungkin ditolak di beberapa titik, oke?

59
00:03:00,590 --> 00:03:03,280
‫Jadi pada titik tertentu, Anda mungkin memiliki

60
00:03:03,280 --> 00:03:06,690
‫penolakan janji yang tidak tertangani di suatu tempat dan jadi izinkan

61
00:03:06,690 --> 00:03:09,860
‫saya menunjukkan kepada Anda bagaimana menghadapinya secara global pada dasarnya.

62
00:03:09,860 --> 00:03:14,070
‫Jadi sekarang mari kita belajar bagaimana menangani penolakan yang tidak tertangani dan

63
00:03:14,070 --> 00:03:16,160
‫kita akan melakukannya di sini.

64
00:03:16,160 --> 00:03:19,530
‫Dan jadi ingat bagaimana di salah satu bagian

65
00:03:19,530 --> 00:03:21,900
‫pertama kursus, kita berbicara tentang acara

66
00:03:21,900 --> 00:03:24,080
‫dan pendengar acara, bukan?

67
00:03:24,080 --> 00:03:28,010
‫Dan sekarang, saatnya untuk benar-benar menggunakan pengetahuan itu.

68
00:03:28,010 --> 00:03:30,940
‫Jadi setiap kali ada penolakan yang tidak

69
00:03:30,940 --> 00:03:34,180
‫tertangani di suatu tempat di aplikasi kita, objek

70
00:03:34,180 --> 00:03:37,470
‫proses akan memancarkan objek yang disebut penolakan yang tidak

71
00:03:37,470 --> 00:03:41,223
‫tertangani dan jadi kita bisa berlangganan acara itu seperti ini.

72
00:03:42,250 --> 00:03:46,903
‫Jadi proses. pada, ingat, dan kemudian

73
00:03:48,004 --> 00:03:52,053
‫nama acara, penolakan tidak tertangani, dan kemudian

74
00:03:52,930 --> 00:03:55,240
‫fungsi panggilan balik

75
00:03:55,240 --> 00:03:59,369
‫di sini menerima kesalahan, jadi mari kita

76
00:03:59,369 --> 00:04:02,793
‫lanjutkan dan mencatat kesalahan ke konsol.

77
00:04:03,780 --> 00:04:08,653
‫Jadi mari kita gunakan err. nama dan kesalahan. pesan.

78
00:04:09,620 --> 00:04:11,640
‫Jadi ini adalah beberapa default yang kami

79
00:04:12,500 --> 00:04:16,073
‫miliki pada semua kesalahan di node.js. js, oke?

80
00:04:17,570 --> 00:04:20,930
‫Oke, dan setelah menyimpan, kita sudah, di

81
00:04:20,930 --> 00:04:24,410
‫sini mendapatkan nama kesalahan dan juga pesan kesalahan.

82
00:04:24,410 --> 00:04:27,940
‫Otentikasi sangat buruk karena, tentu saja, kami memiliki kata

83
00:04:27,940 --> 00:04:29,490
‫sandi yang salah.

84
00:04:29,490 --> 00:04:32,360
‫Jadi sekarang, penolakan janji yang tidak tertangani

85
00:04:32,360 --> 00:04:33,960
‫sekarang benar-benar ditangani.

86
00:04:33,960 --> 00:04:37,430
‫Dan tentu saja, bukan hanya satu dari koneksi yang gagal

87
00:04:37,430 --> 00:04:40,410
‫ini tetapi penolakan janji lainnya yang mungkin tidak

88
00:04:40,410 --> 00:04:44,260
‫kita tangkap di suatu tempat di aplikasi ditangani di sini di

89
00:04:44,260 --> 00:04:46,880
‫final ini, sebut saja jaring pengaman, oke?

90
00:04:46,880 --> 00:04:49,890
‫Jadi kita selalu harus berasumsi bahwa kita sebagai

91
00:04:49,890 --> 00:04:51,410
‫programmer akan membuat kesalahan.

92
00:04:51,410 --> 00:04:54,740
‫Jadi selalu yang terbaik untuk memiliki tempat sentral seperti

93
00:04:54,740 --> 00:04:56,560
‫ini untuk menangani semua

94
00:04:56,560 --> 00:04:59,132
‫penolakan janji seperti jaring pengaman terakhir, oke?

95
00:04:59,132 --> 00:05:01,800
‫Sekarang, jika kita benar-benar memiliki beberapa masalah

96
00:05:01,800 --> 00:05:04,890
‫dengan koneksi database, seperti yang kita miliki dalam contoh

97
00:05:04,890 --> 00:05:07,840
‫ini, maka aplikasi kita tidak akan bekerja sama sekali.

98
00:05:07,840 --> 00:05:09,760
‫Jadi yang bisa kita

99
00:05:09,760 --> 00:05:12,820
‫lakukan di sini adalah mematikan aplikasi kita, oke?

100
00:05:12,820 --> 00:05:17,053
‫Jadi untuk mematikan aplikasi, kami menggunakan proses. keluar.

101
00:05:18,140 --> 00:05:20,420
‫Dan kami sebenarnya sudah menggunakannya

102
00:05:20,420 --> 00:05:22,850
‫sebelumnya dalam skrip di mana kami

103
00:05:22,850 --> 00:05:27,080
‫mengimpor semua data ke dalam database dari file JSON, ingat?

104
00:05:27,080 --> 00:05:29,660
‫Jadi proses. keluar dan kemudian

105
00:05:29,660 --> 00:05:31,810
‫di sini, kita benar-benar dapat memberikan kode.

106
00:05:31,810 --> 00:05:34,140
‫Dan kode nol berarti sukses

107
00:05:34,140 --> 00:05:36,800
‫dan satu berarti pengecualian yang tidak tertangkap.

108
00:05:36,800 --> 00:05:40,230
‫Dan itulah yang biasanya digunakan di sini, oke?

109
00:05:40,230 --> 00:05:43,400
‫Jadi biasanya, Anda akan selalu melihatnya seperti ini.

110
00:05:43,400 --> 00:05:46,970
‫Dan mari kita tambahkan seperti log di sini, konsol. log unhandler penolakan,

111
00:05:50,293 --> 00:05:51,973
‫sesuatu seperti

112
00:05:56,020 --> 00:05:57,560
‫ini.

113
00:05:57,560 --> 00:05:59,860
‫Jadi Anda lihat, saya sangat suka ini, yang ini di sini.

114
00:06:02,910 --> 00:06:04,650
‫Biarkan saja ini simpul...

115
00:06:04,650 --> 00:06:06,730
‫Tidak benar-benar pengguna tetapi

116
00:06:06,730 --> 00:06:09,320
‫log kami yang kami matikan, oke?

117
00:06:09,320 --> 00:06:12,330
‫Dan sekarang, Anda melihat bahwa aplikasi tersebut benar-benar mogok.

118
00:06:12,330 --> 00:06:16,515
‫Dan itu karena proses ini. keluar dari sini, oke?

119
00:06:16,515 --> 00:06:18,860
‫Sekarang, hanya ada satu masalah

120
00:06:18,860 --> 00:06:20,480
‫dengan cara kami

121
00:06:20,480 --> 00:06:23,430
‫mengimplementasikannya sekarang, yaitu, cara kami menerapkannya di

122
00:06:23,430 --> 00:06:26,990
‫sini jadi proses saja. exit adalah cara

123
00:06:26,990 --> 00:06:30,420
‫yang sangat mendadak untuk mengakhiri program karena ini

124
00:06:30,420 --> 00:06:34,030
‫akan segera membatalkan semua permintaan yang saat ini masih

125
00:06:34,030 --> 00:06:38,300
‫berjalan atau tertunda dan itu mungkin bukan ide yang baik, oke?

126
00:06:38,300 --> 00:06:41,550
‫Dan biasanya, apa yang kita lakukan adalah mematikan dengan

127
00:06:41,550 --> 00:06:44,210
‫anggun di mana kita pertama kali menutup

128
00:06:44,210 --> 00:06:47,140
‫server dan baru kemudian, kita mematikan aplikasi, oke?

129
00:06:47,140 --> 00:06:47,973
‫Jadi ayo...

130
00:06:47,973 --> 00:06:51,440
‫Sebelum kita melakukan itu, kita perlu menyimpan

131
00:06:51,440 --> 00:06:55,670
‫server di sini pada dasarnya ke sebuah variabel, oke?

132
00:06:55,670 --> 00:06:59,650
‫Dan hasil dari memanggil app. mendengarkan adalah server dan sekarang,

133
00:06:59,650 --> 00:07:04,650
‫di server itu, kita dapat mengatakan server. close yang akan, seperti namanya,

134
00:07:05,810 --> 00:07:08,400
‫menutup server dan kemudian setelah itu

135
00:07:08,400 --> 00:07:10,490
‫selesai, itu akan menjalankan

136
00:07:10,490 --> 00:07:14,810
‫fungsi panggilan balik yang kami berikan ke dalamnya dan hanya

137
00:07:14,810 --> 00:07:16,130
‫di sini,

138
00:07:16,130 --> 00:07:19,310
‫di mana kami kemudian mematikan server, oke?

139
00:07:19,310 --> 00:07:22,240
‫Dan dengan melakukan ini, dengan melakukan server. close, kita

140
00:07:22,240 --> 00:07:25,630
‫beri server, pada dasarnya waktu untuk menyelesaikan semua request

141
00:07:25,630 --> 00:07:28,890
‫yang masih pending atau sedang ditangani pada saat

142
00:07:28,890 --> 00:07:31,180
‫itu, dan baru setelah itu, server

143
00:07:31,180 --> 00:07:32,910
‫pada dasarnya dimatikan, oke?

144
00:07:32,910 --> 00:07:34,620
‫Jadi ketika kita memberikan

145
00:07:34,620 --> 00:07:37,020
‫brankas, itu tidak akan terlihat persis

146
00:07:37,020 --> 00:07:39,880
‫sama karena, (tertawa) ya, kita seperti satu-satunya yang

147
00:07:39,880 --> 00:07:42,850
‫benar-benar mengakses aplikasi ini tetapi dalam skenario dunia

148
00:07:42,850 --> 00:07:45,960
‫nyata, kita harus selalu melakukannya seperti ini, oke ?

149
00:07:45,960 --> 00:07:48,200
‫Dan tentu saja, itu tidak

150
00:07:48,200 --> 00:07:50,520
‫ideal bahwa aplikasi itu macet, bukan?

151
00:07:50,520 --> 00:07:53,120
‫Karena saat ini tentu saja aplikasi tidak

152
00:07:53,120 --> 00:07:55,448
‫berjalan, tidak berfungsi sama sekali bukan?

153
00:07:55,448 --> 00:07:59,570
‫Dan biasanya, dalam aplikasi produksi di server web, kami biasanya

154
00:07:59,570 --> 00:08:01,690
‫memiliki beberapa alat yang memulai

155
00:08:01,690 --> 00:08:05,100
‫ulang aplikasi tepat setelah macet, atau juga beberapa platform

156
00:08:05,100 --> 00:08:08,120
‫yang menghosting node. js secara

157
00:08:08,120 --> 00:08:11,164
‫otomatis akan melakukannya sendiri, oke?

158
00:08:11,164 --> 00:08:13,920
‫Karena tentunya kita tidak ingin membiarkan aplikasi

159
00:08:13,920 --> 00:08:15,590
‫menggantung seperti ini selamanya.

160
00:08:15,590 --> 00:08:18,420
‫Jadi itu juga tidak berguna, oke?

161
00:08:18,420 --> 00:08:20,410
‫Jadi pada dasarnya, beginilah cara Anda

162
00:08:20,410 --> 00:08:22,590
‫menangani janji yang ditolak dan tidak ditangani.

163
00:08:22,590 --> 00:08:25,130
‫Jadi sekali lagi, pada dasarnya, kami mendengarkan

164
00:08:25,130 --> 00:08:27,930
‫acara penolakan yang tidak tertangani ini, yang kemudian

165
00:08:27,930 --> 00:08:30,100
‫memungkinkan kami untuk menangani

166
00:08:30,100 --> 00:08:32,280
‫semua kesalahan yang terjadi dalam

167
00:08:32,280 --> 00:08:34,470
‫kode asinkron yang sebelumnya tidak ditangani.

168
00:08:34,470 --> 00:08:38,050
‫Tapi sekarang, Anda mungkin bertanya, bagaimana dengan kode sinkron?

169
00:08:38,050 --> 00:08:40,110
‫Di mana kita akan menangani itu?

170
00:08:40,110 --> 00:08:43,020
‫Dan jawabannya terletak, seperti yang bisa Anda bayangkan,

171
00:08:43,020 --> 00:08:44,523
‫di video berikutnya.