WEBVTT

00:00.110 --> 00:00.800
خوش آمدید.

00:00.800 --> 00:02.780
در این ویدیو چیزی واقعاً جالب برای شما دارم.

00:02.780 --> 00:06.500
و آن هم استک فراخوانی و نحوه کار استثناها در استک فراخوانی است.

00:06.500 --> 00:10.970
بنابراین یک مثال کوچک از کدی که از قبل آماده شده دارم.

00:10.970 --> 00:12.920
و چند متد داریم.

00:12.920 --> 00:17.240
بنابراین ما یک متد استاتیک به نام level one داریم که level two را فراخوانی می‌کند.

00:17.240 --> 00:19.940
حالا واضح است که ممکن است کد بیشتری در اینجا وجود داشته باشد.

00:19.940 --> 00:23.480
می‌تواند 15، 50، 100 خط کد باشد.

00:23.480 --> 00:29.270
و در نهایت، در این مورد، واضح است که فقط داشتن یک متد که متد دیگری را فراخوانی کند بی‌فایده است.

00:29.270 --> 00:31.550
اما معمولاً شما کد بیشتری در آن خواهید داشت.

00:31.550 --> 00:35.120
بنابراین این فقط برای نمایش است.

00:35.120 --> 00:38.210
حالا این متد level one متد level two را فراخوانی می‌کند.

00:38.210 --> 00:43.100
و در داخل متد level two ما همچنین یک سری کد داریم، کد زیادی که فقط اجرا می‌شود و غیره.

00:43.100 --> 00:44.600
اما سپس من یک استثنا در داخل level two پرتاب می‌کنم.

00:44.600 --> 00:49.190
حالا در این مورد من به‌طور فعال آن را پرتاب می‌کنم تا کسی بتواند آن را مدیریت کند.

00:49.190 --> 00:56.570
پس این کسی که هست؟

00:56.570 --> 00:58.100
این کسی می‌تواند توسعه‌دهنده باشد.

00:58.100 --> 01:01.760
بنابراین خطا به‌سادگی اتفاق می‌افتد.

01:01.760 --> 01:03.380
برنامه من کرش می‌کند و من می‌دانم که خوب، یک خطا وجود دارد که باید بهتر مدیریت شود.

01:03.380 --> 01:13.250
یا کسی در بالای استک وجود دارد که خطا را مدیریت می‌کند.

01:13.250 --> 01:17.330
پس بالا رفتن از استک به چه معناست و چگونه می‌توان آن را مدیریت کرد؟

01:17.330 --> 01:22.610
خوب، ما قبلاً دیدیم که وقتی می‌گوییم پرتاب، یک خطا به‌سادگی اتفاق می‌افتد.

01:22.640 --> 01:24.110
برنامه ما کرش می‌کند.

01:24.110 --> 01:31.460
اما این کاملاً درست نبود زیرا در مورد جدیدی که در اینجا داریم، ما سعی می‌کنیم

01:31.460 --> 01:37.160
متد level one را اجرا کنیم، که سپس به نوبه خود متد level two را فراخوانی می‌کند، که سپس خطا را پرتاب می‌کند.

01:37.160 --> 01:41.240
بنابراین ما سعی می‌کنیم چیزی را اجرا کنیم که واقعاً باعث خطا می‌شود.

01:41.240 --> 01:44.540
اما سپس ما یک خطا را با یک استثنا می‌گیریم.

01:44.540 --> 01:46.310
ما فقط چیزی را به کنسول می‌گوییم.

01:46.310 --> 01:49.910
مثل این مورد که می‌گوییم Console.WriteLine استثنا در main فراخوانی شد.

01:49.910 --> 01:52.970
و سپس فقط به ما پیام می‌دهد که خوب.

01:52.970 --> 01:56.630
پس بیایید این را اجرا کنیم و ببینیم چه اتفاقی می‌افتد.

01:56.630 --> 01:59.990
و می‌بینید که من این خطا را دریافت می‌کنم که می‌گوید استثنا در main گرفته شد.

01:59.990 --> 02:02.690
چیزی اشتباه است اما برنامه من هنوز در حال کار است.

02:02.690 --> 02:03.500
می‌توانم نشان دهم.

02:03.500 --> 02:07.310
بنابراین برنامه هنوز در حال اجرا است.

02:07.310 --> 02:16.040
و سپس بیایید این یکی را اینجا فراخوانی کنیم CW برنامه در حال اجرا قبل از بلوک try.

02:16.070 --> 02:20.180
خوب، بیایید دوباره آن را اجرا کنیم و خواهیم دید که برنامه در حال اجرا قبل از بلوک try است.

02:20.180 --> 02:21.440
و سپس استثنا در main فراخوانی می‌شود.

02:21.440 --> 02:24.620
چیزی اشتباه است و سپس می‌گوید برنامه هنوز در حال اجرا است.

02:24.620 --> 02:31.820
بنابراین آنچه می‌توانیم ببینیم این است که مدیریت خطا در بالای استک اتفاق می‌افتد.

02:31.820 --> 02:37.730
بنابراین آنچه که ما انجام دادیم این است که مشکل خود را به بالای استک منتقل کردیم.

02:37.730 --> 02:42.860
بنابراین در این مورد ما آن را از level two به level one منتقل کردیم.

02:42.860 --> 02:51.260
و سپس level one آن را به متد main منتقل کرد که در آن بلوک try وجود داشت که سپس استثنا را مدیریت می‌کند.

02:51.260 --> 02:52.580
این استثنای پرتاب شده.

02:52.580 --> 02:54.380
بنابراین در مورد بسیار ساده‌ای که در اینجا داریم، ما تمام کد را می‌بینیم.

02:54.380 --> 03:01.010
و ما کنترل بر روی کد داریم.

03:01.010 --> 03:02.810
و می‌توانیم تمام کد را ویرایش کنیم.

03:02.810 --> 03:04.460
اما در یک پروژه بزرگ که شما در حال ساخت آن هستید با افراد زیادی، مانند یک شرکت با ده‌ها توسعه‌دهنده

03:11.570 --> 03:16.700
یا حتی فقط با دو توسعه‌دهنده، نه همه به تمام کد دسترسی دارند و نه

03:16.700 --> 03:18.860
همه مسئول تمام کد هستند.

03:18.860 --> 03:25.280
اما آنچه می‌توانید انجام دهید این است که فقط بگویید، هی، در این لحظه در کد، می‌خواهم یک خطا اتفاق بیفتد

03:25.280 --> 03:26.540
چون چیزی اشتباه است.

03:26.540 --> 03:27.560
چیزی درست نیست.

03:27.560 --> 03:33.410
و اگر ما فقط به مراحل بعدی ادامه دهیم، ما پایگاه داده‌مان را خراب خواهیم کرد یا چیزی را خراب خواهیم کرد.

03:33.410 --> 03:34.670
من خطا را پرتاب می‌کنم و حالا لطفاً بروید و خطا یا استثنا را مدیریت کنید.

03:40.700 --> 03:44.510
استثنا را بگیرید، آن را مدیریت کنید یا نکنید.

03:44.510 --> 03:45.980
اگر این کار را نکنید، برنامه کرش می‌کند.

03:45.980 --> 03:48.770
اما اگر این کار را کنید، عالی است، پس برنامه کرش نخواهد کرد.

03:48.770 --> 03:55.940
اما مدیریت استثنا، مدیریت استثنا در یک لایه دیگر در یک سطح بالاتر از استک اتفاق می‌افتد.

03:55.940 --> 03:58.730
خوب، پس این چگونه کار می‌کند؟

04:01.490 --> 04:08.030
خوب، وقتی ما یک استثنا پرتاب می‌کنیم، کد درون یک متد استثنا را پرتاب می‌کند و زمان اجرا

04:08.030 --> 04:12.530
سپس شروع به جستجوی متدی می‌کند که می‌تواند استثنا را مدیریت کند.

04:12.530 --> 04:13.820
در این مورد ما آن را دیدیم.

04:13.820 --> 04:17.450
متد main می‌تواند استثنا را مدیریت کند زیرا این همان چیزی است که بلوک try بود، درست است؟

04:17.450 --> 04:22.760
نگاه کردن به بالای استک فراخوانی از نقطه‌ای که استثنا پرتاب شده است، که در سطح ما است.

04:22.760 --> 04:29.600
بنابراین اگر خطایی اتفاق بیفتد، بیایید واقعاً این را کمی بیشتر اجرا کنیم.

04:29.600 --> 04:32.990
بنابراین من یک خط اینجا اضافه می‌کنم تا بهتر بفهمیم.

04:32.990 --> 04:36.770
شما می‌توانید ببینید که این خط قبلاً خاکستری شده است زیرا می‌گوید این خط هرگز اجرا نخواهد شد.

04:36.770 --> 04:37.790
حتی زحمت نکشید.

04:37.790 --> 04:44.270
اما می‌توانم چیزی مانند level two بعد از پرتاب بگویم.

04:44.270 --> 04:52.760
خوب، بنابراین اجازه دهید به شما نشان دهم که level two قبل از پرتاب و بعد از پرتاب اجرا خواهد شد.

04:52.760 --> 04:59.390
بنابراین اجازه دهید این را اجرا کنیم و می‌توانیم ببینیم که برنامه در حال اجرا قبل از بلوک try است، level two قبل از پرتاب سپس.

04:59.590 --> 05:01.810
استثنا فراخوانی می‌شود و برنامه هنوز در حال اجرا است.

05:01.810 --> 05:10.060
بنابراین می‌بینید، این پرتاب باعث کرش برنامه ما نشد، اما به‌طور پیش‌دستانه متد خود را ترک کرد.

05:10.060 --> 05:17.110
بنابراین متد level two فقط گفت، هی، می‌دانی چه، متد level two، تو قادر به مدیریت یا

05:17.110 --> 05:20.380
مدیریت استثنای من نیستی.

05:20.380 --> 05:22.720
پس لطفاً آن را به بالادستی‌های خود بده.

05:22.720 --> 05:24.910
به level one بده.

05:24.910 --> 05:27.130
Level one می‌گوید، می‌دانی چه، این مشکل من نیست.

05:27.130 --> 05:28.690
من آن را به رئیس می‌دهم.

05:28.690 --> 05:29.710
متد main.

05:29.710 --> 05:36.400
متد main می‌گوید، خوب، می‌دانی چه، level one، من خطای تو را مدیریت می‌کنم حتی اگر این

05:36.400 --> 05:37.780
خطای level two باشد.

05:37.780 --> 05:40.240
اما بله، اینگونه است که کل فرآیند بالا رفتن کار می‌کند.

05:40.240 --> 05:42.520
بنابراین واقعاً به دنبال یک مدیریت‌کننده است.

05:42.520 --> 05:49.210
بنابراین کسی که سعی در مدیریت یا کسی که می‌تواند خطا را مدیریت کند و سپس استثنا را مدیریت می‌کند.

05:49.210 --> 05:51.760
و اگر نتواند استثنا را مدیریت کند.

05:51.760 --> 05:57.160
بنابراین اگر این بلوک catch استثنای صحیح را نداشته باشد، در مورد ما ما یک استثنای پیش‌فرض داریم

05:57.160 --> 05:58.930
که تمام استثناها را می‌گیرد.

05:58.930 --> 06:04.810
اما اگر این مانند یک استثنای آرگومان باشد، اما ما چیزی دیگر مانند یک استثنای تقسیم بر صفر را پرتاب کنیم، به عنوان مثال.

06:04.810 --> 06:07.630
بنابراین در این مورد ممکن است کار نکند.

06:07.630 --> 06:11.740
خوب.

06:11.740 --> 06:12.370
بنابراین این فقط یک مثال است از اینکه چگونه استک فراخوانی کار می‌کند به این معنا که یک متد متد دیگری را فراخوانی می‌کند

06:20.530 --> 06:21.400
متد دیگری را فراخوانی می‌کند.

06:21.400 --> 06:22.780
و این غیرمعمول نیست، درست است؟

06:22.780 --> 06:25.930
این اتفاق می‌افتد هر زمان که ما از یک متد استفاده می‌کنیم.

06:25.930 --> 06:32.740
ما می‌بینیم که هر متدی که ما فراخوانی می‌کنیم از متد main فراخوانی می‌شود، که در حال حاضر شروع به

06:32.740 --> 06:34.150
ساختن استک می‌کند.

06:34.150 --> 06:39.010
بنابراین اگر متدی که ما در متد main فراخوانی می‌کنیم متد دیگری را فراخوانی کند، آنگاه استک ما

06:39.010 --> 06:41.290
یک بار دیگر افزایش می‌یابد و غیره.

06:41.290 --> 06:41.860
خوب.

06:41.860 --> 06:44.260
بنابراین این فقط یک مثال کوچک بود.

06:44.260 --> 06:45.520
امیدوارم از آن لذت برده باشید.

06:45.520 --> 06:52.570
این برای نشان دادن نحوه کار استک است، اینکه چگونه می‌توانید خطا یا استثنای خود را به سطحی منتقل کنید

06:52.570 --> 06:55.990
که می‌تواند مدیریت شود یا مدیریت نشود، و سپس برنامه کرش خواهد کرد.

06:55.990 --> 06:56.620
خوب.

06:56.620 --> 06:59.980
بنابراین این برای این ویدیو است، به هر حال.

06:59.980 --> 07:02.980
بیایید فقط به سرعت آن را ثابت کنیم، خوب؟

07:02.980 --> 07:09.730
بنابراین بگویید من فقط استثنای تقسیم بر صفر را می‌پذیرم یا استثنای تقسیم بر صفر را مدیریت می‌کنم.

07:09.730 --> 07:12.940
بنابراین اگر من این برنامه را اکنون اجرا کنم، کرش خواهد کرد.

07:13.090 --> 07:17.080
بنابراین می‌گوید برنامه در حال اجرا قبل از بلوک try، level two قبل از پرتاب.

07:17.080 --> 07:19.270
و سپس بعد از آن هیچ کاری نمی‌کند.

07:19.270 --> 07:22.270
بنابراین فقط به ما این استثنای سیستم را می‌دهد.

07:22.270 --> 07:23.590
چیزی اشتباه است.

07:23.590 --> 07:27.760
بنابراین این همچنین به شما نشان می‌دهد که شما می‌توانید.

07:28.000 --> 07:30.370
و اجازه دهید این را به یک استثنای پیش‌فرض تبدیل کنم.

07:30.370 --> 07:38.260
دوباره والد می‌داند چگونه فرزندان را مدیریت کند، اما فرزندان نمی‌دانند چگونه والد را مدیریت کنند

07:38.260 --> 07:39.310
به طرز جالبی.

07:39.310 --> 07:39.760
درست است؟

07:39.760 --> 07:45.160
بنابراین استثنا والد است و تقسیم بر صفر فرزند است.

07:45.160 --> 07:45.640
درست است؟

07:45.640 --> 07:53.080
بنابراین اگر من سعی کنم به عنوان تقسیم بر صفر سعی کنم والد استثنا را مدیریت کنم، کار نمی‌کند.

07:53.080 --> 07:59.680
اما اگر من سعی کنم یک استثنای فرمت اینجا داشته باشم، به عنوان مثال، آن کار خواهد کرد، خوب؟

07:59.680 --> 08:01.990
بنابراین هنوز برنامه من کرش نخواهد کرد.

08:01.990 --> 08:03.520
بنابراین هنوز برنامه را فراخوانی کرده است.

08:03.790 --> 08:06.760
استثنا در main خوب.

08:06.760 --> 08:11.230
بنابراین این مقدار زیادی اطلاعات بود.

08:11.260 --> 08:12.490
نگران نباشید.

08:12.490 --> 08:17.680
ما به طور قابل توجهی احساس بهتری از وراثت خواهیم داشت.

08:17.680 --> 08:25.840
و ما موقعیت‌های خطای بیشتری خواهیم دید که ما آنها را می‌گیریم، سعی می‌کنیم و می‌گیریم و نهایی می‌کنیم،

08:25.960 --> 08:32.590
به‌ویژه زمانی که به فصل‌های پایگاه داده و رابط کاربری می‌رسیم، زیرا هر زمان که

08:32.590 --> 08:36.850
شما با یک رابط کاربری کار می‌کنید، چیزی می‌تواند اشتباه پیش برود زیرا کاربر می‌تواند هر کاری انجام دهد.

08:36.850 --> 08:38.740
پس در ویدیو بعدی می‌بینمتان.
```