l23: updating#000124

Author: Saeid Darvish

index.rst

@@ -49,7 +49,6 @@
    lessons/l21
    lessons/l22
    lessons/l23
-   lessons/l24
    log
    donate-report
    python-interactive

lessons/l23.rst

@@ -177,7 +177,7 @@
 
 در زبان‌های برنامه‌نویسی صدای اعتراض یک Exception قابل درک و تشخیص است و می‌توان برای آن‌ها فرآیندی را پیش‌بینی کرد که بروز آن‌ها نه تنها باعث اتمام برنامه نشود بلکه برنامه بتواند در مسیر درست به اجرای خود ادامه دهد.
 
-در زبان برنامه‌نویسی پایتون دستور ``try/except`` برای همین منظور فراهم دیده شده است [`اسناد پایتون <https://docs.python.org/3/reference/compound_stmts.html#the-try-statement>`__]. 
+در زبان برنامه‌نویسی پایتون دستور ``try/except`` برای همین منظور فراهم دیده شده است [`اسناد پایتون <https://docs.python.org/3/reference/compound_stmts.html#the-try-statement>`__] و در ادامه به بررسی انواع ساختار قابل پیاده‌سازی از این دستور خواهیم پرداخت.
 
 ``try/except``
 ------------------------
@@ -400,10 +400,6 @@
   شی Exception که توسط دستور ``except`` دریافت می‌گردد تنها در داخل بدنه همان دستور ``except`` در دسترس خواهد بود، چرا که بلافاصله پس از اتمام دستورات داخل بدنه آن ``except``، شی مذکور نیز به صورت خودکار حذف می‌گردد.
 
 
-
-
-
-
 ``try/except/else``
 ------------------------
 
@@ -681,6 +677,47 @@
     ******************************
     --------> Finished!
 
+روند انتشار Exception
+----------------------------
+
+در تمام مثال‌هایی که در این بخش ارائه شد، برای ساده‌سازی مطلب تنها به بررسی مدیریت خطا داخل یک تابع پرداختیم. ولی باید این مورد را در نظر داشته باشید، زمانی که یک Exception رخ می‌دهد، این Exception به ترتیب مراحل فراخوانی را به ابتدای اجرا در برنامه طی می‌کند و هر بار چنانچه یک handler (دستور ``try`` با ``except`` مناسب) پیدا نشود، این Exception به مرحله پیش‌تر تحویل داده می‌شود تا شاید یک handler برای آن پیدا شود. این روند تا رسیدن به اسکریپت (فایل py. اصلی برنامه) ادامه می‌یابد و در صورت عدم پیش‌بینی handler آنگاه Exception در این نقطه بروز و منجر به توقف کل برنامه می‌گردد. به عنوان مثال نمونه کد زیر را در نظر بگیرید:
+
+
+.. code-block:: python
+    :linenos:
+
+    def print_sum_div_first(a, b):
+        sum = a + b
+        div = sum / a
+        print(div)
+
+
+    def action(a, b):
+        try:
+            if isinstance(a, int):
+               print_sum_div_first(a, b)
+
+        except ZeroDivisionError as err:
+            print(f'[action function ERROR!!!] {err.__class__.__name__}')
+
+
+    try:
+        action(5, 6)    # Successfully
+        action(0, 8)    # raise ZeroDivisionError
+        action(3, 'G')  # raise TypeError
+
+    except Exception as err:
+        print(f'[module ERROR!!!] {err.__class__.__name__}')
+
+::
+
+    2.2
+    [action function ERROR!!!] ZeroDivisionError
+    [module ERROR!!!] TypeError
+
+در نمونه کد بالا همانطور که مشخص است تمام Exceptionها در داخل تابع ``print_sum_div_first`` رخ می‌دهد ولی از آنجا که این تابع فاقد handler می‌باشد، Exceptionها به یک مرحله قبل‌تر یعنی تابع ``action`` تحویل می‌گردند، ولی این تابع تنها یک handler برای ``ZeroDivisionError`` داشته پس تمامی Exceptionهای احتمالی دیگر از جمله ``TypeError`` به یک مرحله قبل‌تر تحویل و خوشبختانه در آن‌جا handle می‌شوند!
+
+
 
 مدیریت خطای تودرتو (Nested Exception Handling)
 ---------------------------------------------------
@@ -690,6 +727,18 @@
 البته از آنجا که در یکی از بندهای فلسفه پایتون آمده: `PEP 20: Flat is better than nested <https://www.python.org/dev/peps/pep-0020/>`__ انجام این‌کار چندان پایتونی نمی‌باشد و برنامه‌نویس احتمالا می‌تواند با کمی دقت بیشر از ساختار تودرتو پرهیز کند و کدی به مراتب خواناتر توسعه دهد. به هر حال امکان این کار در زبان برنامه‌نویسی پایتون برای برنامه‌نویس محفوظ نگه‌داشته شده است.
 
 
+کارایی (Performance)
+----------------------------
+
+همیشه این سوال مطرح می‌شود که آیا بهتر است با کنترل شرط و پیاده‌سازی چندین دستور ``if`` از بروز Exception جلوگیری کنیم یا خیلی ساده این وظیفه را به یک ساختار handler بسپاریم. کدام روش کارایی بهتری دارد؟
+
+زبان برنامه‌نویسی پایتون از نظریه «درخواست بخشش راحت‌تر از کسب اجازه است» پیروی می‌کند [`EAFP: Easier to ask for forgiveness than permission <https://docs.python.org/3/glossary.html?highlight=eafp#term-eafp>`__]. بر همین اساس پایتون به صورت پیش‌فرض تمام مقادیر را صحیح فرض می‌کند و زمانی اگر خلاف این فرض رخ دهد، آنگاه برای عرض پوزش به دنبال یک handler مناسب می‌گردد!
+
+مطمئنا سربار handle کردن یک Exception از یک دستور ``if`` بیشتر است ولی تنها وقتی یک Exception به handler نیاز پیدا می‌کند که رخ بدهد! پیشنهاد پایتونی برای این مسئله ترجیح بر استفاده از دستور ``try/except`` می‌باشد تا دستور ``if``، چرا که هم خوانایی کد بیشتر می‌شود و هم از آنجایی که در صورت استفاده از دستور ``if`` روند اجرای کنترل و بررسی شرط هربار در برنامه رخ می‌دهد ولی عمل جستجو برای یافتن ``except`` مناسب تنها در زمان رخ دادن Exception انجام خواهد شد، کارایی بهتری کسب می‌گردد.
+
+
+[`مطالعه بیشتر:‌ پرسش و پاسخ مرتبط در StackOverflow <https://stackoverflow.com/q/7604636>`__]
+
 
 
 Exception Hierarchy

lessons/l24.rst

@@ -11,6 +11,16 @@
 
 
 
+.. raw:: html
+
+    <p class="rubric" id="00124" ><a class="reference external" href="#00124">00124</a> - سه‌شنبه ۱۰ فروردین ۱۴۰۰</p>
+
+* بروزرسانی: مبحث «روند انتشار Exception» به درس بیست و سوم اضافه گردید.
+* بروزرسانی: مبحث «کارایی (Performance)» به درس بیست و سوم اضافه گردید.
+
+
+
+----
 
 
 .. raw:: html